Delegate as the first parameter to the extension method

Question

Ladies and men

I recently tried this experiment:

static class TryParseExtensions { public delegate bool TryParseMethod<T>(string s, out T maybeValue); public static T? OrNull<T>(this TryParseMethod<T> tryParser, string s) where T:struct { T result; return tryParser(s, out result) ? (T?)result : null; } } // compiler error "'int.TryParse(string, out int)' is a 'method', which is not valid in the given context" var result = int.TryParse.OrNull("1"); // int.TryParse.OrNull<int>("1"); doesnt work either // compiler error: type cannot be infered....why? var result2 = TryParseExtensions.OrNull(int.TryParse, "2"); // works as expected var result3 = TryParseExtensions.OrNull<int>(int.TryParse, "3"); var result4 = ((TryParseExtensions.TryParseMethod<int>)int.TryParse).OrNull("4"); 

I am interested in two things:

• Why can't the compiler output a parameter of type "int"?

• Do I understand correctly that extension methods are not found in delegate types, since I think that they really have this type (but are a "method") that only match the delegate signature? As such solves this. Would it not be possible to allow the operation of scenario 1 (and not specifically, of course, but in general)? I think, from the point of view of the language / compiler, and would it really be useful, or am I just (trying) wildly abusing here?

Looking forward to some thoughts. Thnx

Answer 1

Here you have a few questions. (In the future, I would recommend that when you have several questions, divide them into several questions, and not into one publication with several questions in it, you will probably get better answers.)

Why the compiler cannot deduce a parameter of type "int" in:

 TryParseExtensions.OrNull(int.TryParse, "2"); 

Good question. Instead of answering this question, I refer to a 2007 article which explains why this does not work in C # 3.0:

http://blogs.msdn.com/b/ericlippert/archive/2007/11/05/c-3-0-return-type-inference-does-not-work-on-member-groups.aspx

To summarize: in principle, there is a problem with the chicken and the egg. We need to do overload resolution on int.TryParse to determine which TryParse overload is supposed (or if none of them work, what the error is). Overload resolution always tries to infer from arguments. In this case, however, this is exactly the type of argument we are trying to make.

We could come up with a new overload resolution algorithm that says “well, if there is only one method in the group of methods, then choose this one even if we don’t know what the arguments are,” but that seems weak. This seems like a bad idea for special case groups that have only one method, because it punishes you for adding new overloads; it may suddenly change.

As you can see from the comments on this article, we received a lot of good reviews. The best feedback was basically "good, suppose the type inference has already worked out the types of all the arguments, and this is the return type that we are trying to do, in which case you can do the overload." This analysis is correct, and the changes in this influence were included in C # 4. I talked about this a little more:

http://blogs.msdn.com/b/ericlippert/archive/2008/05/28/method-type-inference-changes-part-zero.aspx

Do I understand correctly that extension methods are not found in delegate types, since I think that they really belong to this type (but are a "method") that only match the delegate signature?

Your terminology doesn't work a bit, but your idea is correct. We do not find extension methods when the “receiver” is a group of methods. More generally, we do not find extension methods when the recipient is something that does not have its own type, but rather accepts a type based on its context: method groups, lambdas, anonymous methods, and a null literal have this property. It would be very strange to say null.Whatever() and call the extension method for String or even weirder (x=>x+1).Whatever() and call the extension method on Func<int, int> .

A specification line describing this behavior:

An implicit conversion of an identity, reference, or box [must exist] from [the expression of the recipient] into the type of the first parameter [...].

Conversions by method groups are not identical, referenced, or boxed conversions; these are method group conversions.

Would it not be possible to allow the operation of scenario 1 (and not specifically, of course, but in general)? I think, from the point of view of the language / compiler, and would it really be useful, or am I just (trying) wildly abusing here?

It's not safe. We have a pretty smart team, and there is no theoretical reason why this is impossible to do. It just doesn't look like a function that adds more meaning to the language than the cost of extra complexity.

There are times when it would be useful. For example, I would like to be able to do this; Suppose I have static Func<A, R> Memoize<A, R>(this Func<A, R> f) {...} :

 var fib = (n=>n<2?1:fib(n-1)+fib(n-2)).Memoize(); 

Instead of what you should write today, it is:

 Func<int, int> fib = null; fib = n=>n<2?1:fib(n-1)+fib(n-2); fib = fib.Memoize(); 

But frankly, the additional complexity that the proposed function adds to the language is not paid due to the small advantage of making the code more or less verbose.

Answer 2

The reason for the first error:
int.TryParse is a group of methods, not an instance of an object of any type. Extension methods can only be called on object instances. This is for the same reason why the following code is invalid:

 var s = int.TryParse; 

This is also the reason the type cannot be inferred in the second example: int.TryParse is a group of methods, not the TryParseMethod<int> .

I suggest you use approach three and abbreviate the name of this extension class. I do not think there is a better way to do this.

Answer 3

Note that your code works if you first declare:

 TryParseExtensions.TryParseMethod<int> tryParser = int.TryParse; 

and then use tryParser where you used int.TryParse .

The problem is that the compiler does not know what int.Parse overload you are talking about. Therefore, he cannot completely do this: are you talking about TryParse(String, Int32) or TryParse(String, NumberStyles, IFormatProvider, Int32) ? The compiler cannot guess and will not arbitrarily decide for you (fortunately!).

But your type of delegate makes it clear what kind of overload you are interested in. Therefore, the appointment of tryParser not a problem. You are no longer talking about a “method group”, but about a well-identified method signature within that method group called int.TryParse .