Question

I’ve noticed that the C# compiler doesn’t infer second generic parameter.
Example:

C++ template code: (yea I know that templates don’t work like generics)

class Test {
public:
template <class T,class V> 
    T test(V v) {
       //do something with v
       return T();
    }
};

int i = 0;
Test t = new Test();
double j = t.test<double>(i); //infers V as int

The templates (and generics) can’t infer return type, so in C++ I give it the first template parameter, and the second template parameter is inferred from the variable type.

Now, same example in C#:

class Test {
    public T test<T,V>(V v) where T: new() {
       //do something with v
       return new T();
    }
};

int i = 0;
Test t = new Test();
double j = t.test<double>(i); //Error Using the generic method 'Test.test<T,V>(V)' requires '2' type arguments

But if i use 1 type, I don’t have to explicitly specify the type:

class Test {
    public V test<V>(V v) where V: new() {
       return new V();
    }
};

int i = 0;
Test t = new Test();
int j = t.test(i); //OK infers V as int.

So, why can’t C# generics infer the second type (while in c++ templates it clearly can) ?
I’m sure it’s designed that way (I doubt they the .Net team overlooked this), so why is it designed this way that I must explicitly specify both types?

Edit:

From the discussions we had in the answers so far, both languages support overloading by number of template parameters.

So again, why is C# designed this way ? What’s different in the language implementation that doesn’t allow to explicitly declare only one parameter ?

Answer 1

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)