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?

Olive

In your example, how would you distinguish between IEnumerable<object> and IEnumerable? Would the first be IEnumerable<>? – Bifocal

typeof(IEnumerable<object>) == typeof(IEnumerable) == typeof(IEnumerable<>).MakeGenericOrSo(typeof(object)) – Olive

The standard solution around here to the file name problem, and I think one sanctioned by the VS team (although I can't find a link at the moment), is to save the file for AGenericType<With,Four,Type,Parameters> with a name like AGenericType`4.cs. – Dwight

This is a discussion, not a question. Sorry for that. Next time I'll use a different forum. But I couldn't delete it because of to many answers and votes. – Olive

One hint for future readers - if you have a real suggestion for a language or framework improvement, create a case at connect.microsoft.com If it gets enough 'up votes' they sometimes look to add in the suggested language features. – Dualistic

Related: is-there-a-reasonable-approach-to-default-type-parameters-generics – Manamanacle

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...

Collyrium

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.

Hillock

It would keep type hiearchies cleaner. Given a A<T=object> and B<T=oejbect>:A<T>, B:A would derive from the same type as B<XY> – Olive

The default type would be subject to all the constraints so subsequent code could remain ignorant. It would basically make IEnumerable the same as IEnumerable<object> (as an example, the real usefulness of the feature comes with more complex architecture) – Scriabin

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.

Lindyline

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.

Saunder