By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
435,247 Members | 1,287 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 435,247 IT Pros & Developers. It's quick & easy.

redefinition of generic methods

P: n/a
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

Apr 26 '06 #1
Share this Question
Share on Google+
3 Replies


P: n/a
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]" <wz*****@nospm.ii.uni.wroc.pl.nospm> ha scritto nel
messaggio news:Oa**************@TK2MSFTNGP05.phx.gbl...
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

Apr 26 '06 #2

P: n/a
> 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
Apr 26 '06 #3

P: n/a
"Laura T." <laura_t@yahoodotdotcom> wrote:
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
Apr 26 '06 #4

This discussion thread is closed

Replies have been disabled for this discussion.