C# 3.0 Return Type Inference Does Not Work On Method Groups

re: C# 3.0 Return Type Inference Does Not Work On Method Groups

David V. Corbin — Mon, 05 Nov 2007 23:30:07 GMT

Eric, I think you just committed "Developer Overloading" <grin>, My brain HURTS.

Actually a very well written explaination. I have often tried to explain the inference process to my clients, only to be met with blank stares. This post will definately help in that regard.

Cheerrs!

re: C# 3.0 Return Type Inference Does Not Work On Method Groups

Luke — Tue, 06 Nov 2007 02:04:41 GMT

I'm a bit confused:

S GetCity<X, S>(X x) { …

var fails = customers.Select(GetCity); // [1]

var alsoFails = customers.Select(c=>GetCity(c)); // [2]

If we had overload resolution that only fails when type information cannot be derived, is there a case where [2] would work and [1] would not? (I don't see how this could be possible.) Perhaps the devil is in the details, but I don't see why it's that hard to specify that overload resolution fails if all the types cannot be determined. Could you shed some light on some of the "subtly incompatible set of overload resolution rules" that would be needed?

re: C# 3.0 Return Type Inference Does Not Work On Method Groups

Eric Lippert — Tue, 06 Nov 2007 03:14:46 GMT

You are correct in that if overload resolution is going to fail for the method group, then it is going to fail in the lambda as well.

The subtlety is this: suppose we decided to go ahead and do overload resolution anyway. In this case we would then deduce that S is R, and therefore deduce that R is... R.

What should we do in that case? Should we have overload resolution pick a different method? That would then be changing the overload resolution rules in a subtle and confusing way.

Suppose we didn't do that. Suppose we added R to R's boundary set. Now suppose we had a different inference path, say from a third argument, from which we would deduce that R is string. Now what do we do to resolve the conflict? There is no implicit conversion from string to R or R to string, so we'd have to have inference fail.

Which seems bad. We could then say well, never add R to R's bounds set. Just ignore it if that happens. Keep on trucking. Which is another subtle change to the type inference algorithm.

And then you have to think about what happens if we are deducing not that R is R, but that, say, R is IConvertible<R>. Or what if there are more complex relationships between the type variable, the inferred return type, and other types in the bounds set.

It gets to be a big mess, and all because we have a circularity whereby we are trying to make an inference both from and to the same thing at the same time. It's logically weird and we just don't want to go there.

re: C# 3.0 Return Type Inference Does Not Work On Method Groups

qrli — Tue, 06 Nov 2007 04:43:40 GMT

Sorry I'm lost in your inference. If we have already get Func<Customer, R>, didn't we already know the argument list of GetCity()? Then it should be straightforward to pick an overload of GetCity() and find the return type. Why does it have to determine return type for overload resolution?

re: C# 3.0 Return Type Inference Does Not Work On Method Groups

Luke — Tue, 06 Nov 2007 06:10:14 GMT

After working on this problem for a while, I realized the same thing as qrli. You should never have made the return and argument type parameters in your posts on variance different than Func<A, R>. :-p I can't decide whether this is important though, due to the fact that we need to imply a delegate type. Is there no way for the type inference engine to know that a method's arguments are completely specified by Func<Customer, R> and that only one overload could possibly be chosen?

You describe the unbroken circle problem when dealing with the generic version of GetCity. However, is it not possible to try overloads that would be a better match than your generic version, overloads for which there are no unknown type parameters? If both the generic and non-generic versions exist and I write the lambda as above, the non-generic version will be chosen. (I assume this is due to §14.4.2.2 of the C# spec.)

If the generic version of GetCity is the only one that exists, [2] fails, so I don't know why we're worrying about making [1] work.

Does overload resolution with lambda methods include any of the subtleties you are trying to avoid with non-lambda overload resolution?

re: C# 3.0 Return Type Inference Does Not Work On Method Groups

Richard — Tue, 06 Nov 2007 14:34:40 GMT

Perhaps this is a stupid question (I don't know C# very well) but... are there any cases where automatically rewriting:

var cities = customers.Select(GetCity);

as:

var cities = customers.Select(c=>GetCity(c));

will do the wrong thing? It seems blatantly obvious that the former is unambiguous, in the given case, so it seems to me to be a bug if C# can't work that out for itself.

re: C# 3.0 Return Type Inference Does Not Work On Method Groups

Eric Lippert — Tue, 06 Nov 2007 17:46:26 GMT

> Why does it have to determine return type for overload resolution?

Overload resolution goes like this (simplified):

* Add all nongeneric methods in the method group to the candidate set.

* Do type inference on all generic methods and add all successful inferences to the candidate set.

* Remove all the nonapplicable methods (ie, where arguments do not go to parameter types) from the candidate set.

* Choose the unique best candidate from the applicable candidates.

You have to determine the return type in order to do step two -- make type inferences on generic methods.

re: C# 3.0 Return Type Inference Does Not Work On Method Groups

Eric Lippert — Tue, 06 Nov 2007 17:49:37 GMT

> However, is it not possible to try overloads that would be a better match than your generic version, overloads for which there are no unknown type parameters?

Yes. That is exactly what I mean by making a subtle change to the overload resolution algorithm just for this case.

We could mess with the overload resolution algorithm in all the ways you suggest, and we'd then have _two_ overload resolution algorithms, one for regular code and one for nested type inference on method groups, which would produce sublty different results. We don't want to go there.

re: C# 3.0 Return Type Inference Does Not Work On Method Groups

Eric Lippert — Tue, 06 Nov 2007 17:52:30 GMT

> If both the generic and non-generic versions exist and I write the lambda as above, the non-generic version will be chosen.

That rule only comes into effect when there is an exact tie, ie, you have Foo(int) and Foo<T>(T) in the candidate set and you call Foo(1). Type inference makes Foo<int> a candidate and the nongeneric is then chosen by the betterness algorithm.

One of the subtleties that you'd run into by messing with the overload resolution algorithm is that now generic methods that otherwise would be chosen as the better match disappear from the candidate set seemingly inexplicably.

re: C# 3.0 Return Type Inference Does Not Work On Method Groups

Eric Lippert — Tue, 06 Nov 2007 18:01:26 GMT

> It seems blatantly obvious that the former is unambiguous

Sure, it is. And we could write a new rule, say, that return type inference from method groups is legal only when it is "blatantly obvious" what method the method group refers to. But we'd then have to write a new "blatantly obvious overload resolution" algorithm which was different from the regular overload resolution algorithm. And now, again, we have two overload resolution algorithms.

I think my point here has been somewhat lost. Let me restate it:

* the specification for return type inference from a lambda explicitly does NOT require the target delegate type to be known.

* the specification for overload resolution on a method group explicitly DOES require the target delegate type to be known. It's not necessary in absolutely every case, but the algorithm does call for knowing what the return type is for overload resolution on a method group containing generic methods.

* in the type inference scenario, the target delegate type is exactly what we are trying to infer; it is unknown.

* therefore it is rather nonsensical to specify that we ought to use overload resolution as an explicit part of return type inference

Or, even more briefly:

* We have designed the type inference algorithm so that we always infer from known to unknown at every step. Return type inference on method groups as specified requires sometimes inferring from unknown to unknown. That wasn't our intention, it wasn't what we implemented, and it got into the published specification by accident.

re: C# 3.0 Return Type Inference Does Not Work On Method Groups

Luke — Tue, 06 Nov 2007 21:13:43 GMT

> One of the subtleties that you'd run into by messing with the overload resolution algorithm is that now generic methods that otherwise would be chosen as the better match disappear from the candidate set seemingly inexplicably.

I keep returning to this and it's bothering me -- do you have an example of such a generic method?

re: C# 3.0 Return Type Inference Does Not Work On Method Groups

qrli — Wed, 07 Nov 2007 05:12:51 GMT

For now, I can understand the case when there is a GetCity<S, R>() generic overload, and it is understandable that the generic parameters cannot be deduced. But I think it will surprise most programmers that it won't work if there's only non-generic GetCity().

I tend to think that there's something wrong with method-group-to-delegate conversion, or accurately, deduction. The conversion from method group to delegate appears to be so significant althought the syntax intents to hide the complexity. I used to think it is trivial but I was surprised to find that Control.Invoke() doesn't accept a method group.

So I got the same question as Richard. Why cannot you do the conversion in the lambda way instead of the method-group-to-delegate way? It seems more powerful to treat method group as a terser form of lambda expression.

re: C# 3.0 Return Type Inference Does Not Work On Method Groups

Stefan Wenig — Wed, 07 Nov 2007 12:52:07 GMT

qrli, Richard,

do you mean resolving the method group as if it were a lambda call, or actually generating a method that does the call?

Just resolving it like this would be fine with me, although I figure Eric's gonna tell us that this is too much of a special case. Still, it would remove this horrible case where noone will understand why referring does not work!

Acutally generating this method would result in some overhead, and I'm not sure if it is acceptable to introduce this overhead just to enable deferring.

Just creating an actual method if the method group cannot be resolved otherwise would create a speial case too, plus it would mean that you have to guess if any overhead is invisibly created, you won't see it in the code. This is hardly how languages like C# work. (Then again, while it is easier to figure out whether an anonymous delegate/lambda results in a closure might be easier than this, it could still be considered a precedent that we don't actually care about such minor performance penalties. After all, the costs of a closure are MUCH higher than creating a method for just passing stuff through).

I understand the language designer's perspective, but in this case I'd vote for some kind of fix that resolves this from a user's perspective. I think it might even be easier to understand the rules of inference if they are the same for method groups as for lambdas. But then again, it might not, and it might lead to breaking changes with existing C# 2.0 code.

re: C# 3.0 Return Type Inference Does Not Work On Method Groups

Luke — Wed, 14 Nov 2007 17:43:19 GMT

Eric, have you abandoned this post (or perhaps been ultra-busy)? The question in my comment above was for you...

Fabulous Adventures In Coding

Vincent — Fri, 21 Mar 2008 12:19:28 GMT

Ayende在使用.Net3.0的时候遇到了这样一个问题Csc.exeanddelegateinference,or:WhyC#hasawkwardsyntax Co...

Fabulous Adventures In Coding

cnblogs.com — Fri, 21 Mar 2008 12:47:04 GMT

Ayende 在使用.Net 3.0的时候遇到了这样一个问题 Csc.exe and delegate inference, or: Why C# has awkward syntax Code highlighting

Method Type Inference Changes, Part Zero

Fabulous Adventures In Coding — Wed, 28 May 2008 18:46:14 GMT

Back in November I wrote a bit about a corner case in method type inference which does not work as expected