re: Type inference woes, part two

Peter Ritchie — Sun, 28 May 2006 13:57:36 GMT

I'd agree with James on the first point. Since "var" doesn't imply type, variable initializer lists shouldn't restrict type and should be considered short-hand for "var x = <value>; var y = <anothervalue>; ..."

For point two, I would expect it to be consistent with the way the language currently handles literals and type coercion; if the literal fits within the type of the variable it is assigned to, then just cast it down, i.e.: Int16 x = 0; Zero will obviously fit within Int16 despite technically being Int32. Since var has no type it must be implied through its initialization, with arrays I would expect it to be consistent with the comma operator's associativity rules: evaluating from left to right. In your example, I would expect x to be an array of ints without error because a short value will not overflow (where "Int64 g = 0;var x = new[] {0, g}" would produce an error because x would be inferred to be int[] and g could overflow).

Point 3 is a little trickier because there really are no associativity rules to use as a baseline, other than from top to bottom. So, me personally, I would expect top-down evaluation. Since the first return is a zero literal, and is an int, the result should be implicitly considered IEnumerable<int>.

Point 4: does lambda always compile into IL, like Generics; or, is it more like C++ templates?

re: Type inference woes, part two

James S. — Fri, 26 May 2006 22:56:25 GMT

With regards to the "var x = 0, y = (short) 123;" example, it's interesting that you don't mention even considering making them different types.

C++0x has considered the same problem, as part of its "auto x = incarnate_verbosity;" syntax. The proposed wording at the linked URL explains that each initialiser should be deduced to the same type or the program is ill formed. Of course, C++, being far less brash than C#, decided to stop considering the array case in recent drafts :)

As for the lambda examples, the question of how the argument type is unified seems like the bigger issue to an outsider... 'c' appears to have latent typing in the example above (the first example, anyway; the second is illegible), making the return type fairly moot (what if the lambda returns a projection of c.Foo?). You haven't mentioned that, so apparently something else is happening: Do you deduce the type of S before knowing what Func<S, T> is and then use that to guide the lambda? Really? How many of them can you chain together? :)