What about optional generic type parameters in C# 5.0? [closed]

Question

Just a thought.

Wouldn't it be useful to have optional type parameters in C#?

This would make life simpler. I'm tired of having multiple classes with the same name, but different type parameters. Also VS doesn't support this very vell (file names) :-)

This would for example eliminate the need for a non-generic IEnumerable:

interface IEnumerable<out T=object>{
  IEnumerator<T> GetEnumerator()
}

What do you think?

Answer 1

I am definitely for it.

I'm currently writing helper methods for different scenarios where I want to pass references to different members and methods of classes. To accomplish this I'm taking, for example, an Expression<Func<TIn, TOut>> as argument to the helper (that lets me reach the method with a lambda expression, thus keeping everything strongly typed).

BUT - I currently need to define a new helper method for each different number of input arguments, since I need to have a different amount of generic arguments to it. Instead of

HelperMethod<TIn>(Expression<Action<TIn>> arg) // Yes, C# can distinguish
HelperMethod<TOut>(Expression<Func<TOut>> arg) // these two from eachother
HelperMethod<TIn, TOut>(Expression<Func<TIn, TOut>> arg)
HelperMethod<TIn1, TIn2, TOut>(Expression<Func<TIn1, TIn2, TOut>> arg)
// etc

I could make do with, at the most, two methods:

HelperMethod<TIn>(Expression<Action<TIn>> arg)
HelperMethod<TOut, TIn1 = DummyType, ...>(Expression<Func<TIn1, ..., TOut> arg)

In my case, it would avoid a lot of code duplication...

Answer 2

What would be the main use for this language feature? I can see that it could help with some administrative tasks like file names and less typing and such but beyond that I don't see how useful this would be.

Also, this feature would significantly complicate any generic constraints that could be placed on the generic type parameter and the default type itself would have to function as a sort of generic constraint itself.

I think this would complicate the language without offering any real benefit to the developer.

Answer 3

It's not clear to me what exactly you are proposing. Currently there may be types with the same name but different type parameters, but which aren't related in any way by inheritance - what would your proposal do then?

Furthermore, if the base class library were redesigned from the ground up, there almost certainly would be no non-generic IEnumerable interface - it only exists because the CLR didn't support generics when the interface was introduced, and the generic interface inherits from it only so that legacy code will continue to work. Newly declared classes are being created for a CLR which does support generics, so that issue is no longer relevant.

Answer 4

I recently came across a case that could have used something like this, just not quite. I had a method that performs a transformation of sorts, between class A and its associated class AChild and class B and class BChild. Usually, the pair A/AChild was the same as B/BChild, but sometimes A was a base class of B and AChild a base class of BChild.

It would have been nice to be able to say that my type parameter TB defaulted to TA, and that TBChild defaulted to TAChild.

Note that this was a situation in which it was necessary to write out the type parameters, as inference would not work.