redefinition of generic methods

[Wiktor Zychla [C# MVP]]

it is obvious that you cannot have two [or more] methods that differ only on
returning value:

void F() { }
int F() { }

it is however interesting (and to me : surprizing) that this restriction
also applies to generic methods that differ on constraints:

T F<T>() where T : class { }
T F<T>() where T : struct { }

note that constraints are strictly exclusive here. it would be deterministic
then for the compiler to pick a method to call:

string s = F<string>(); // pick first F
int i = F<int>(); // pick second F

I do not think that this is a compiler-only issue, I belive it is rather
caused by IL limitations. However, since .NET constraints are significantly
limited, I belive it would be easy to determine if constraints are exclusive
or not in general case [Am I wrong?].

Wiktor Zychla

 

[Laura T.]

Wouldn't this complicate type inference to be also constraint binding?
IMHO, if would complicate quite a lot the final type binding (lookup).
I don't think it's an IL limitation. You could have F<X>'1 and F<X>'2.

Laura

 

[Wiktor Zychla [C# MVP]]

Wouldn't this complicate type inference to be also constraint binding?

IMHO, if would complicate quite a lot the final type binding (lookup).

could you think of any specific example?

I don't think it's an IL limitation. You could have F<X>'1 and F<X>'2.

is it possible in the same class?

Wiktor Zychla

 

[Barry Kelly]

Wouldn't this complicate type inference to be also constraint binding?
IMHO, if would complicate quite a lot the final type binding (lookup).
I don't think it's an IL limitation. You could have F<X>'1 and F<X>'2.

The x in `x refers to the number of generic parameters. Generic types in
..NET are overloaded on the basis of arity (number of parameters) only. So
some F<> is in CLR nomenclature F`1. F`2 would be some F<,>

-- Barry