471,627 Members | 2,312 Online
Bytes | Software Development & Data Engineering Community
Post +

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 471,627 software developers and data experts.

Generic parameter deduction

Hi all,

I have a method where the compiler is unable to deduce the generic
arguments. Now I'm asking myself if this a bug, or if not, why it isn't
working. The method in question is Foo3:

using System;
using System.Collections.Generic;

namespace ConsoleApplication10
{
class Program
{
class A<T> { }
class B<T> { }

static A<T> Foo1<T, AA>(AA a, T t) where AA : A<T>
{
return default(A<T>);
}
static A<T> Foo2<T, AA>(AA a, B<T> t) where AA : A<T>
{
return default(A<T>);
}
static A<T> Foo3<T, AA>(AA a) where AA : A<T>
{
return default(A<T>);
}
static void Main(string[] args)
{
A<int> ai = new A<int>();

ai = Foo1(ai, 42);
ai = Foo2(ai, new B<int>());

// ... gives CS0411, can't deduce generic parameter. Why?
ai = Foo3(ai);
}
}
}

The compiler can deduce T for Foo1, as it is explicitly defined as a
parameter. It also can infer T & AA in Foo2, although T is only there
implicitly as an generic argument.
But if it can handle Foo2, why not Foo3?

TIA,
Andy
--
To email me directly, please remove the *NO*SPAM* parts below:
*NO*SPAM*xmen40@*NO*SPAM*gmx.net
Dec 24 '05 #1
4 2918
Andreas Mueller <me@privacy.net> wrote:
I have a method where the compiler is unable to deduce the generic
arguments. Now I'm asking myself if this a bug, or if not, why it isn't
working. The method in question is Foo3:
<snip>
static A<T> Foo3<T, AA>(AA a) where AA : A<T>
{
return default(A<T>);
}


Looking at section 27.6.4 of the draft ECMA spec (the numbering keeps
changing, unfortunately - "Inference of type arguments" is the sub-
clause name) gives *some* light.

Each argument/parameter is processed in turn. Fortunately, we've only
got one to deal with here - the parameter of "AA a" and the argument of
"ai" (with type A<int>).

Given that AA is a method type parameter, it *looks* like we should go
for the option which says that type inference succeeds for this
parameter, and the type of AA is A<int>.

Unfortunately, I don't see anything in the spec which says that
inference should then take the constraints into account and further
infer what it can (in this case that T is int).

In neither Foo1 nor Foo2 is the constraint needed to work out T, which
is why there isn't a problem. (In the case of Foo2, the second
parameter is of a constructed type, and the last option in the spec
occurs, inferring T.)

I don't know whether this is the answer you were hoping for, and I'm
not *100%* sure it's right - I've been reading the spec quite a lot
recently, so I'm reasonably "in tune" with it, but there are some
tricky bits like this...

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Dec 24 '05 #2
Jon Skeet [C# MVP] wrote:
Andreas Mueller <me@privacy.net> wrote:
I have a method where the compiler is unable to deduce the generic
arguments. Now I'm asking myself if this a bug, or if not, why it isn't
working. The method in question is Foo3:

<snip>

static A<T> Foo3<T, AA>(AA a) where AA : A<T>
{
return default(A<T>);
}

Looking at section 27.6.4 of the draft ECMA spec (the numbering keeps
changing, unfortunately - "Inference of type arguments" is the sub-
clause name) gives *some* light.

Each argument/parameter is processed in turn. Fortunately, we've only
got one to deal with here - the parameter of "AA a" and the argument of
"ai" (with type A<int>).

Given that AA is a method type parameter, it *looks* like we should go
for the option which says that type inference succeeds for this
parameter, and the type of AA is A<int>.

Unfortunately, I don't see anything in the spec which says that
inference should then take the constraints into account and further
infer what it can (in this case that T is int).


I think that is the point, it needs the constraint to resolve the
parameter. If it is not spec'd, it is not a bug, but a feature request.

In neither Foo1 nor Foo2 is the constraint needed to work out T, which
is why there isn't a problem. (In the case of Foo2, the second
parameter is of a constructed type, and the last option in the spec
occurs, inferring T.)

I don't know whether this is the answer you were hoping for, and I'm
not *100%* sure it's right - I've been reading the spec quite a lot
recently, so I'm reasonably "in tune" with it, but there are some
tricky bits like this...

Hi Jon,

this answer really helped me! What do you think about it? Should it
work? (I'm a bit spoiled from C++ templates, so I'd say yes :-) ).I'll
reread the spec and may log a feature request at MS.

Cheers,
Andy
--
To email me directly, please remove the *NO*SPAM* parts below:
*NO*SPAM*xmen40@*NO*SPAM*gmx.net
Dec 25 '05 #3
Andreas Mueller <me@privacy.net> wrote:
Unfortunately, I don't see anything in the spec which says that
inference should then take the constraints into account and further
infer what it can (in this case that T is int).


I think that is the point, it needs the constraint to resolve the
parameter. If it is not spec'd, it is not a bug, but a feature request.


Yup.
In neither Foo1 nor Foo2 is the constraint needed to work out T, which
is why there isn't a problem. (In the case of Foo2, the second
parameter is of a constructed type, and the last option in the spec
occurs, inferring T.)

I don't know whether this is the answer you were hoping for, and I'm
not *100%* sure it's right - I've been reading the spec quite a lot
recently, so I'm reasonably "in tune" with it, but there are some
tricky bits like this...


this answer really helped me! What do you think about it? Should it
work? (I'm a bit spoiled from C++ templates, so I'd say yes :-) ).I'll
reread the spec and may log a feature request at MS.


You certainly might as well. I've made a note for the specification
committee, but in more of a "note that this means" rather than "this
should be fixed" way - MS is probably a better avenue for that.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Dec 26 '05 #4
Please do submit a feature request. I've wished for the same thing.

Jesse

Dec 26 '05 #5

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

3 posts views Thread by SimonH | last post: by
3 posts views Thread by Marcel Sebbao | last post: by
4 posts views Thread by Neelesh | last post: by
2 posts views Thread by yaniv.golan | last post: by
6 posts views Thread by Tim Frink | last post: by
1 post views Thread by XIAOLAOHU | last post: by
reply views Thread by leo001 | last post: by

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.