Method Type Inference Changes, Part One

re: Method Type Inference Changes, Part One

Konstantin Triger — Wed, 18 Jun 2008 10:10:19 GMT

An implementation question:

Quoting you:

"Type inference infers T as Customer, but cannot figure out what R is because Customer does not have a property FristName. Therefore type inference fails, ...".

It seems that at this point you can say: "Compilation fails". Why do you need to see it as an inference failure and then go back to find the "user friendly" cause? It looks correct to stop processing in a case a member was not found in a type and report an error.

In a more general case you will probably try to infer T as other type and if it's possible check whether it has "FristName" property. So the generic error I would expect here is something like: "Neither of types <Customer,'other inferred types if exist'> has a property named 'FirstName'".

re: Method Type Inference Changes, Part One

configurator — Wed, 18 Jun 2008 12:56:09 GMT

At that point, the method has not been selected yet, so the type T as Customer.

i.e., there might be another Select in the candidate pool, which would make that code valid - The contents of the lambda cannot be compiled (or even generate an error) until the method is selected; The method cannot be selected because the contents cannot compile. This recursion is exactly the problem that Eric is refering to.

re: Method Type Inference Changes, Part One

nikov — Wed, 18 Jun 2008 19:36:49 GMT

Hi, Eric.

>If they can, then the constructed generic method stays in the candidate set; if inference fails then it is removed.

>Then all methods which are inapplicable -- that is, the arguments cannot be converted to the parameter types -- are removed.

One important thing which happens between these two steps -- check that once the inferred type arguments are substituted for the corresponding method type parameters, all constructed types in the parameter list satisfy their constraints, and if they do not -- remove this generic method. This step differs from the final validation of constaraints on the best method itself (if it is generic), which happens after overload resolution.

In the following example the method A.Foo is removed early due to constraint on the delegate F<T>, and so the extension method is invoked. If we remove the constraint from the delegate, A.Foo becomes the best method and then compilation fails.

using System;

class A

{

delegate T F<T>() where T : class;

void Foo<T>(F<T> x) where T : class { }

static void Main()

{

new A().Foo(() => 1);

}

static class B

{

public static void Foo<T>(this T x, Func<int> f) { }

}

re: Method Type Inference Changes, Part One

Eric Lippert — Wed, 18 Jun 2008 19:49:47 GMT

Indeed, I am glossing over a number of important steps here.

Also, as a result of a bug that I think was one of yours, we also check to see whether any of the inferred types would be illegal because they are not accessible in the caller's context.

re: Method Type Inference Changes, Part One

Tanveer Badar — Thu, 19 Jun 2008 07:23:27 GMT

The user would be correct to expect as clear an error message as possible, in that example. Because missing property on the type is the real problem.

I appreciate the work gone/going into improving error messages. Now, only if I could convince my ridiculous management to move to C#3.0.

re: Method Type Inference Changes, Part One

kostat — Mon, 23 Jun 2008 18:36:12 GMT

To configurator:

Basically the inference algorithm can be seen as a series of:

<hypothesis> -> <test> -> …

As the implementation is described, it assumes some <hypothesis> (T is Customer), then makes a <test> (does Customer has a property named 'FristName'?). The <test> fails and invalidates <hypothesis>.

Since the user is interested which <test> failed, the implementation then uses some heuristic to find the <test>. My point is that it is always known. See again Eric's explanation: "if inference fails then it [the candidate] is removed". In fact what fails is the <test>! So there can be a situation where we need to remove unneeded <test>s in our error message, but never - to find them again.

re: Method Type Inference Changes, Part One

RuneFS — Fri, 27 Jun 2008 13:35:55 GMT

I had an interresting (at lest to me) experience. I had the following few lines of code:

public IDictionary<string, IDictionary<string, object>> Find<TKey>(IEnumerable<TKey> searchValues, IDictionary<string, Type> requireColumns) {

IDictionary<int, string> keys;

keys = searchValues.ToDictionary(x => Convert.ToInt32(x), x => identifiers[x]);

that works fine the types of the ToDictionary can be inferred, but chagning the last line to:

keys = searchValues.ToDictionary(Convert.ToInt32, x => identifiers[x]);

fails. My question is how come that the inferrance fails in the last version? after all the type of the first argument is the same and can be determined or am I missing something?

re: Method Type Inference Changes, Part One

Eric Lippert — Fri, 27 Jun 2008 18:05:40 GMT

Reread part zero of this series. Your question is the whole reason I'm doing this series in the first place.

re: Method Type Inference Changes, Part One

RuneFS — Mon, 30 Jun 2008 10:41:29 GMT

Thanks for pointing that out, i'll get back to part zero at once :-)