Generics can’t infer second parameter? [duplicate]

C# has been designed to be a slightly less brain-bending language than C++.

In particular, I don’t think it’s a great idea to compare C# generics to C++ templates for various reasons – they’re fundamentally two really quite different approaches to accomplishing similar things in some situations. The C++ approach is certainly flexible in some ways – although it doesn’t allow (as I understand it) templates which only exist in binary form, or new template specializations to be created at execution time. Basically the C++ templating approach doesn’t sit well with the rest of how .NET fits together.

Now as for why you can’t specify some type arguments and allow others to be inferred (which is a language decision rather than a platform decision; I’m sure it would be feasible as far as .NET itself is concerned) – again, I believe this is for the sake of simplicity. Choosing the exact right method and the right type arguments is already extremely complicated in C# – more complicated than most C# developers can get their heads round. It involves:

  • Potentially considering methods up the type hierarchy from the compile-time type of the target
  • Overloading by number of parameters
  • Overloading by the number of type parameters
  • The effect of named arguments
  • The effect of optional parameters
  • The effect of generic type parameter constraints on parameter types (not constraints specified by the target method, note)
  • Method group to delegate conversions
  • Anonymous function conversions
  • Type inference for type arguments
  • Dynamic typing
  • Generic covariance and contravariance

Personally, I think that’s enough to get my head around, without allowing yet more possiblities via “M can still be a candidate if it has at least as many type parameters as specified type arguments”. Would you also want named type arguments and optional type parameters? 😉

I’ve looked at overloading quite a lot, following the spec thoroughly etc. I’ve found areas which make the language designers scratch their heads and try to work out what the compiler should do. I’ve found areas which the compiler definitely gets wrong. I wouldn’t want to add any more complexity here without a really good reason.

So yes, it’s basically for the sake of simplicity, and sometimes that’s a pain – but often you can work around it. For every potential feature, you need to consider:

  • The benefit of the feature to end developers
  • The cost of the feature to end developers in terms of time spent understanding it
  • The cost to the language designers in designing and specifying it thoroughly
  • The cost to the compiler writers in implementing it correctly
  • The cost to the test team in testing it thoroughly (in conjunction with everything else around overloading)
  • The cost to future potential features (if this one makes the language more complicated, that leaves less “potentially grokable” additional complexity for other features)

Leave a Comment