Lambda Expressions vs. Anonymous Methods, Part Four

re: Lambda Expressions vs. Anonymous Methods, Part Four

Name (required) — Tue, 27 Mar 2007 04:13:54 GMT

Extension methods are another potential source for adding potential signatures.

I assume that lambda expressions take extension methods into account when resolving signatures.

For example, Add a ToUpper to In32 (whatever that may mean...) and M((int x)=>x.ToUpper()); should resolve fine.

re: Lambda Expressions vs. Anonymous Methods, Part Four

Eric Lippert — Tue, 27 Mar 2007 07:56:06 GMT

Sure. Almost all of the rules of semantic analysis are the same inside a lambda body as in a normal method.

re: Lambda Expressions vs. Anonymous Methods, Part Four

jmlovero — Wed, 28 Mar 2007 00:05:47 GMT

If the compiler has a choice between an extension method and a native method when trying to resolve an overload, which one will it pick? Or will it throw an exception? Let's use the example that "Name (required)" provided and say that M((int x)=>x.ToUpper()); resolves because we've created a ToUpper() method that takes and returns an Integer. What happens?

re: Lambda Expressions vs. Anonymous Methods, Part Four

Eric Lippert — Wed, 28 Mar 2007 01:06:57 GMT

If there are two or more applicable instance methods and we cannot determine which is better, we do NOT start looking for instance methods. We give an error as usual.

If there are one or more applicable instance methods and we can determine which is best, we bind to the best instance method.

Otherwise, there must be zero applicable instance methods. We look for extension methods.

The rules for how we look for extension methods are complicated and I can go into them in detail if you would like. Suffice to say that we start looking in the current namespace for an extension method with the right name. If we can't find one then we step out one level of namespace, etc.

re: Lambda Expressions vs. Anonymous Methods, Part Four

Eric Lippert — Wed, 28 Mar 2007 01:13:15 GMT

So in the example you mentioned, we would try both overloads for M. If some strange person did an extension method on int to make x.ToUpper() legal on ints, then both overloads would be applicable candidates. Since neither is better than the other, we would give an ambiguity error.

In general, not just in the lambda binding case, introducing new possible bindings for any given name is a potentially breaking change. It can change working code into code that has overload resolution ambiguities. However the problem is _particularly_ pernicious in lambdas because of this ability to try multiple type bindings in a lambda and pick the one that works.

We do NOT recommend introducing extension methods willy-nilly. As the draft spec states, "Extension methods are less discoverable and more limited in functionality than instance methods. For those reasons, it is recommended that extension methods be used sparingly and only in situations where instance methods are not feasible or possible."

re: Lambda Expressions vs. Anonymous Methods, Part Four

jmlovero — Wed, 28 Mar 2007 21:06:10 GMT

Thanks for the insight, Eric. Your post was extremely informative as usual.

I'm a bit surprised that you don't favor instance methods over extension methods as a way to disambiguate method calls. I can understand the decision, but might it have been better to favor the instance method and give a compiler warning about the ambiguity? This would avoid unforseen breaking changes due to the introduction of an extension method. Was there a debate over this sort of thing on the compiler team? Is it your opinion that any ambiguity is bad enough that the code should not compile?

re: Lambda Expressions vs. Anonymous Methods, Part Four

Eric Lippert — Wed, 28 Mar 2007 21:30:21 GMT

We DO favour instance methods over extension methods when disambiguating method calls.

I think I was insufficiently clear in my description above.

What we need to do is determine whether the int or the string version of M (or both) is applicable.

Clearly the string version is a candidate.

If there is an extension method on int such that the int version of the lambda can be successfully bound, then it is a candidate too.

At this point we now need to decide which overload is better, and in this case neither is better. We do not consider any of the reasons why a particular body bound successfully when deciding which is better. We do not say "well, this body bound with twelve extension methods, but this other version of the body bound with only six extension methods, so the version with six is better". "Betterness" is determined solely by examining the types and the conversions, not any details of why the conversion succeeded.

However, if we are in a situation where we have to choose between an instance method and an extension method, it is not even a choice. If there is ANY applicable instance method, we either choose it or produce an ambiguity error. We NEVER choose an applicable extension method over an applicable instance method.

Lambda Expressions vs. Anonymous Methods, Part Five

Fabulous Adventures In Coding — Fri, 07 Sep 2007 01:32:36 GMT

Last time I demonstrated that the compiler could have to do an exponential number of bindings in order

Learning WPF with BabySmash - Factories, Interfaces, Delegates and Lambdas, oh my!

Readed By Wrocław NUG members — Sun, 15 Jun 2008 18:31:01 GMT

NOTE: If you haven't read the first post in this series, I would encourage you do to that first