OSNews

No, not AFAIK. Certainly not prior to "2.0", and I still believe they are not (I have not been involved with C# for some time...)

Ok, that's what I thought.

ormandj is correct, however this is generally seen as a good thing amongst the .Net developer crowd, i.e. C++ templates are turing complete, but that allows you to shoot your foot off quite easily, whereas the fact that C# generics are not lends itself to a stricter programming paradigm.

Just a footnote to ormandj's comment (and you might already known this): the C# compiler was built from the ground up (meaning pre 1.0) with generics in mind, they just weren't added to the C# language itself until C# 2.0...if you look through ROTOR for CLI 1.0 you can see it firsthand. So they'll probably never be turing complete.

Ok, I was just curious. To be honest, I never liked the idea of templates or generics, but I can see why language designers would choose them rather than more elegant solutions to keep the language from becoming too radical.

Edited 2006-10-08 03:15

I'm genuinely curious: what'd be a more elegant solution, in your opinion?

Well, templates/generics aren't really needed in a dynamically typed language.

Of course, a lot of people prefer static languages, in which case I suppose you would need some sort of generics construct, so I guess they aren't inelegant in the context of static languages.

I have found C# generics to be very useful and elegant solution for writing class libraries, frameworks etc. Once you are used to generics way of coding, its hard to not use it.

Are there other solutions the solve the problems that generics solve?

ccknight beat me to the question, and I'm honestly curious as well. The learning curve for generics is dead simple compared to templates, and IMO it's a very elegant solution since the compiler does all of the work for you as far as type safety checks go. I've yet to see it's equal in other languages.

C++ templates are probably its only saving grace; the language is otherwise without any redeeming value due to its overwhelming bug-inducing complexity. It's hard to not like the idea of parameterized types, and it should be hard to not like many of the features present in C++ that are usually missing in other languages like specialization and partial specialization. D is also fairly respectable in this regard, but as we all suspect, it will never obtain any sort of popularity and so might as well not exist as far as the average programmer is concerned.

C#'s generic facilities suffer too much from their Java++ nature: they should have been part of the language from the beginning and used throughout the framework. That and some brain damage like using signed integers as the basis for indices and other such things where negative values make no sense and require manual error-handling to toss out superfluous exceptions so as to obtain interoperability with VB.NET are just some of the many reasons the .NET framework doesn't impress me terribly. Blub, indeed.

Let's say that you want to create a class with a type parameter with the constraint that operator +, operator -, operator /, and operator * are defined. So you create an interface IArithmetic but you can't create instances with int or long as type parameters, because they do not implement the IArithmetic interface. Now you could handle this sort of type resolution structurally (which goes against the inheritance model of C#) or you can define an interface so that any kind of native numeric type can be the type parameter because someone is bound to want this. The former is the better solution, but not doing the latter is just retarded because your generic code can't deal with those types. Without specialization, you can't even shoe-horn it together so that the consumer of your library can just use it without caring that you've had to duplicate your effort because your development environment is retarded.

Another failing of C# generics is the absence of a feature like a "typedef" that would permit you to export instantiations of a parameterized type with a given type parameter with some typename. You can make your consumer create lots of ad-hoc typenames via the using keyword, but making your client's life difficult by making them type in SomeClass<SomeType, SomeType2<SomeType> > somewhere in their source file when they don't need to know/care that you were able to express your code generically is hardly advantageous.

Now these are just off the top of my head. I'm sure if I were to think about the issue I could come up with other topical weaknesses.

It's hard to not like the idea of parameterized types, and it should be hard to not like many of the features present in C++ that are usually missing in other languages like specialization and partial specialization.

The idea of parameterized types is just dandy. Sane uses of it, like the STL, are great. It's the idea of perverting the feature to serve as a macro system that bothers me. I didn't use to feel this way, but the more I used stuff like Boost the more it pissed me off. That and the god-aweful syntax, which is hard for both humans and compilers to parse...

Let's say that you want to create a class with a type parameter with the constraint that operator +, operator -, operator /, and operator * are defined. So you create an interface IArithmetic but you can't create instances with int or long as type parameters, because they do not implement the IArithmetic interface

What makes this even more fun is that in c# operators are static and interfaces do not contain static members.

To get around this you end up having to definine an IOperations&lt;T&gt; interface and provide implementations of Add, Subtract, etc for each numeric type.

Then you can create a Number&lt;T, O&gt; where O : IOperations&lt;T&gt; that defines all the regular operators and then you can finally write:

public T Add&lt;T, C&gt;(T a, T b) where C : IOperations&lt;T&gt;
{
Number&lt;T,C&gt; a2 = a;
Number&lt;T,C&gt; b2 = b;
return a2 + b2;
}

...

int c = Add&lt;int,Int32Ops&gt;(10, 5);

Yay.... This article goes into more detail: http://www.osnews.com/story.php?news_id=7930

How would generics be Turing complete? Generics are an extension to the type system, and as such have no computational capability.

C++ templates are Turing complete, but that's because they're a hideous mixture of generics and a macro language in one feature.

Everything is inherited from something else, I didn't think anyone was claiming that generics in C# is a breakthrough in computing technology; just a really good addition to C#. For a staticly typed language like C# generics are a must in my mind. Do you know how dirty I felt using an ArrayList or HashTable and having to set/get Object types *shivers*. Now, I can just use my List<> and Dictionary<> and be happily type safe