C# doubts on generics

First of all: there are always design decisions also for language design, runtime environments, etc. From that perspective, the "why" question is often simply answered by "since the people in charge felt it is a good decision - or they did not think of it to be useful" ;-)

I have several items I'd love to have in C#/CLR, but they do not exist - so I have to work around or simply live with the current state of it.
- real RAII support
- better generic constraint support
- generic properties
- static interface methods
- ...

You can view generic concept as code generators: you write *one* template construct that generates usable code when parametrized with real types.
Generics allow to reduce copy-paste code. Instead of writing e.g. a Stack class for int, string, MyElement class, etc., a generic Stack class provides all the useful functions of a Stack, for any concrete type - *once for all*!

The early C# versions did not provide generics support, but only the awkward object-based version, which always required down-casting (BTW, I consider casting a code-smell in most of the cases).

To your questions:

1. counter question: any good example for a generic enum type definition and usage?
2. as mentioned above: it's you deciding if you consider some code to be useful to be parameterized by generics - containers are a good example where it is useful
3. C# (like any other programming language) usually provide some syntactic-sugar[^] to write more expressive code. Properties, indexers, (un)registring to events, constructors, destructors are special functions that get translated into some underlaying functions that have reserved names (Property: get_Property/set_Property, Indexer: get_Item/set_Item, Event: add_Event/remove_Event, Constructor: .ctor/.cctor, Destructor: .dtor. You cannot declare these special functions as generics - they can only be part of some outer generic definition (e.g. a generic class can contain properties, but a single property cannot be defined with it's own generic parameters since the syntax does not allow for this and not because it would not make sense - this was a language design decision).
   
   For your question on indexer: you are free to *not* define an indexer in your class, but instead define two methods (e.g. TElement getAt(int pos);/void setAt(int pos, TElement item);).
4. This is a weird question: you might want to re-phrase to make it more clear. What aspect of performance are you concerned about? As mentioned above, generic classes are code generators: write once, use multiple (parametrized by type). Inheritance or implementing interfaces (is this what you mean by "virtual classes"?) have no runtime speed impact (if this is what you mean by "performance") - except first time JIT compiling when other assemblies have to be loaded.
5. The cited phrase does not make sense, please give a link to the original document. The designers of C# seem to have put some effort in supporting generic containers also for older C# code. So, they decided that a generic List class *implements* the generic as well as the non-generic IList *interfaces* (as well as other generic and non-generic interfaces).

Cheers
Andi

Doubts are good ! When you stop having doubts, it is time to worry :)

I'll add a few thoughts here to the excellent responses of Ron and Andreas, but, first, a few general comments on what I believe is helpful in learning, and achieving mastery of, a programming language like C# in its "context" in the .NET FrameWork, and specific technology stacks, like Windows Forms, or WPF, and as a context for what can be loosely described as "object-oriented programming."

... begin sermon ...

You can spend a lot of time studying a programming language from "the top down," looking at how it implements what every programming language must implement ... flow-of-control ... conditional branching ... data storage and retrieval, transformation of data, re-usable components, etc.

And, you can easily become confused by the complexity of the implementation of something like C# and come to believe there are "principles" you don't understand that must explain what you see, and experience, as the quirks (or even contradictions) in the implementation.

Well, the problem is that there's lots of quirks :). And many of them just reflect the design decisions of the language creators, and the build-up of layer-after-layer of added-on features, and extensions.

The "danger" of "top-down" study is that you may waste a lot of time learning everything about the horse, its evolution, its anatomy, horse diseases, etc., but not be able to ride it, well.

Is it possible that you are somewhat over-concerned at this point with figuring out what it all means rather than getting-on with learning how to use it ?

... end of sermon ...

1)Why does CLR not allow the creation of generic enumerations?

This is like asking why chickens have feathers rather than hides like a crocodile, and can't sing like the bulbul: because the language evolved that way, by design. Enumerations are designed to be a "lightweight" grouping of named Constants for utility purposes, and they have a special functionality available, if used with the Flags Attribute, for bit-wise operations.

Specifically, Enums are designed to be compile-time Constants, and must be initialized where they are declared.

2)Classes encapsulate algorithms which can be applied on types so we have generic classes, similarly methods can also encapsulate algorithms so we can have generic methods(Correct me if i am wrong). So can i say that which ever entity that is subjected to an algorithm can be treated as a generic entity?

The word "algorithm" comes to us from the name of the great 16th. century Baghdad mathematician, Al Khwarazimi, mis-translated (confused with the Greek root ἀριθμός) in the so-called "Middle Ages" in Europe. It has been "re-purposed" in modern times to mean a systematic method for solving (or converging on a solution for) certain problems which are logical, as well as, mathematical.

Now that the word "algorithm" has moved into wide popular usage, outside mathematics, and computer science, the term has become "overlayed" with all kinds of cultural "baggage," and its meaning is less "distinct."

You can say that Classes, and computer Applications as a whole, express algorithms, use algorithms, implement algorithms.

I see no connection between the topic of algorithms and the specific computer-science programming language construct of "generic classes."

Perhaps it's valuable to think of the difference between a "method," and a "technique" ?

3)What is an indexer method? How does it qualify to become a generic method?

... revised based on Ron Beyer's comment ...

A method of supplying a means for access (sequential or random) via the special syntax [] to some Class/Struct, etc., you wish to "behave like" other .NET objects that use the [] syntax like: Array, List, string, etc.

I see no relevant connection between "indexer" and the general topic of generic methods. .NET supplies many objects which have

A custom indexer can be as simple as defining one extension method, as shown here: [^].

I can't make sense of your question which asks about how an indexer method it "becomes" a generic method. Are you thinking that an extension method is a generic method ?

4)Generics dont have many virtual classes. How does having a fewer virtual classes increase the performance of generic entities?

I see no connection between "virtual classes" and "generics:" not clear, to me, what you are asking about.

5)We have both generic and non generic interface for backward compatibility, actually speaking i read a sentence which states the reason for backward compatibility : It goes like this:

.NET evolved: new features were added, but the old features the new features extended, or enriched, were kept for compatibility: so old code won't break. This is absolutely the way that software, and programming languages, and operating systems, evolve: they are all (for better, and for worse) forced to support legacy code.

"If the List class implemented only the IList interface, no code could consider a List object an IList.". I couldnt understand the meaning of this statement."

The Generic List facilities in .NET 2.0 implement all kinds of Interfaces:

IList<T>, ICollection<T>, IEnumerable<T, IList, ICollection, IEnumerable

Those are choices the language designers made, but, you are not alone in asking (at least I think you are asking): why couldn't IList ... which implements some of the same Interfaces ... have been used without some of the other inherited Interfaces ?

If you really want to explore the deep black-hole of this particular "why," then I suggest you read Eric Lippert's (key member of the .NET team for many years, and a guru's guru) blog entry on the topic: [^].

best wishes for your continued progress !