Implicit typing; why just local variables?

Jared has a fantastic link in his answer, to a fantastic topic.

I think it does not answer the question explicitly.

Why not?

var getFoo() {
    return new Foo(); 
}

The reason for this is:

What if?

class Foo {}

var GetFoo() {
   return GetBar(); 
}

var GetBar() {
  return GetBaz(); 
}

var GetBaz() {
   return new Foo();
}

You could deduce that GetFoo is going to return Foo, but you will have to trace through all the calls that method makes and its children makes just to infer the type. As it stands the C# compiler is not designed to work in this way. It needs method and field types early in the process before the code that infers types can run.

On a purely aesthetic level I find the var definitions on methods confuse things. Its one place where I think being explicit always helps, it protects you from shooting your self in the foot by accidentally returning a type that causes your signature and a ton of other dependent method signatures to change. Worst still, you could potentially change all you signatures of a method chain without even knowing you did so if you return the value of a method that returns object and happened to be lucky.

I think var methods are best left for dynamic languages like Ruby

Eric Lippert did an entire blog post on the subject.

• https://docs.microsoft.com/en-us/archive/blogs/ericlippert/why-no-var-on-fields

In summary, the main problem is that it would have required a major re-architecture of the C# compiler to do so. Declarations are currently processed in a single pass manner. This would require multiple passes because of the ability to form cycles between inferred variables. VB.NET has roughly the same problem.