Earlier quoted context omitted.
Miguel I'm confused then - your experience with Mono certainly means you have a better understanding, but I thought I understood it pretty well, too. Places lacking type inference: - Parameter definitions - Method return types - Generic type parameters (sometimes) - Lambda expressions (due lack of syntax to indicate quoted code) - Field declarations The only place type inference works for declarations is in local var…
"var" is a shorthand to not declare the type when it can be inferred, in most cases to avoid Foo foo = new Foo(). The point is that it avoid repetitive typing, while still preserving type safety and everything that comes with it: compiler checking that right types are used in the right places. [Digression While it is possible to use in var foo = GetIt() the practice is discouraged because it makes the type of "foo" o…
In fact, the lack of type inference for fields was said to be due to technical limitations in the C# compiler implementation, not for any language reason. [1] Sure, any product will have limitations due to schedules/resources, but that doesn't change the fact that they're unfortunate limitations that could be fixed. C# hasn't addresses these issues, but they've had 2 or 3 releases since they were introduced.
>For a parameter definition, its use clearly makes no sense. What is the type for the following method? >void Demo (var x) {}
In that case, x has no constraints (it's unused), so it's generic. Pretty simple. An unused parameter isn't that useful outside of a few cases. Usually you'll use the variable, and constraints can be inferred. Or you'll find a constraint that limits the type to a concrete type. Here's some examples:
void dub (var x) { Tuple.Create(x,x); } // x is T
void uri (var x) { new Uri(x); } // x is string
void cmp (var x, var y) { Nullable.Compare(x, y); } // x and y are Nullable where T : struct
Arguing against return type inference is wierd: C# does that in anonymous functions - certainly you don't think we should have to annotate types there!
As for type signatures changing, if you need want to keep public contracts, then write them out! No one is saying you need to always infer everywhere, just that it's a great aid. Also, this particular example just demonstrates why C#'s type coercion is a bad idea, albeit understandable, given their desire to follow C style.
Generic type parameters. What do you mean it makes no sense? I can't write, e.g. "new List() { 1 }" - it complains List needs a type parameter. Another example: "Func = () => 1". Nope, I'm required to explicitly provide the type. What if C# didn't have syntax support for Nullable? You'd have to do e.g. "x = new Nullable(1)" or create a helper function like Tuple and have e.g. "x = Nullable.Create(1)". Generic type parameter inference only happens on methods.
Also note that C# can't infer generic type parameter constraints - you've got to annotate them all by hand. Makes sense, I guess, because it doesn't infer any generic type parameter definitions, either.
Lambda expressions can't be type inferred. "var x = () => 1" does not work (CS0815). This is because of the same syntax for expression trees versus anonymous functions. And if that was changed, you'd still need to "promote" func somehow, due to C#'s wierd nominal typing for delegates.
Fixed statements can't be type inferred either: error CS0821: Implicitly-typed local variables cannot be fixed.
The things you mentioned, for (and foreach), using -- those are all local variable declarations. So we have it working for local variables, for some generic type parameters, lambda parameter definitions (when the lambda type is known) and lambda return types.
It's a nice start, and it makes C# far more enjoyable than some other languages like Java. But it's still quite limited, without solid reasons.
1: http://blogs.msdn.com/b/ericlippert/archive/2009/01/26/why-n...