1

Possible Duplicate:
Implicit typing; why just local variables?

c# allows this:

public class MyClass
{
    public void Foo()
    {
        var q = new MyObject();
    }
}

But it won't allow this:

public class MyClass
{
    var q = new MyObject();

    public void Foo()
    {
        // ...
    }
}

Is there a reason for this? Thanks.

Community
  • 1
  • 1
Esteban
  • 3,108
  • 3
  • 32
  • 51
  • 2
    Because noone wrote the spec, coded it, and tested it. – asawyer Sep 18 '12 at 18:23
  • 5
    http://blogs.msdn.com/b/ericlippert/archive/2009/01/26/why-no-var-on-fields.aspx – Servy Sep 18 '12 at 18:23
  • 1
    Not only that, but considering that [non-private] members are *an exposed API* it would be too easy to leak details accidentally or introduce breaking changes. –  Sep 18 '12 at 18:24

1 Answers1

5

You can only use type inference for local variables.

The var keyword infers types for variables "that are declared at method scope". In terms of the language, var is used to define an "implicitly typed local variable declaration" (C# Language Spec 8.5.1). The language only uses var for local variables, not type-level variables.

As to why, it's a matter of how the C# designers intended it. It was not intended to infer types for all usages, only for a specific scenario. Eric Lippert described why this was done, providing many potential pitfalls that expanding the usage would cause, including potentially publically exposing an anonymous type, chaining multiple initializers, and more.

Reed Copsey
  • 554,122
  • 78
  • 1,158
  • 1,373
  • The question is **why** it's defined that way. –  Sep 18 '12 at 18:25
  • So why did they intend it only for this specific scenario, and not for that other scenario too? Or, lacking insight into their brains, what reasons do you see for that? –  Sep 18 '12 at 18:28
  • 1
    @delnan I just posted a link with some great insights -but it was intended only for locals. I suspect the entire rationale was purely for LINQ and anonymous types, both of which only need support in locals to work. Expanding the usage leads to a huge number of potential pitfalls (see Eric's post) – Reed Copsey Sep 18 '12 at 18:30
  • Great, now you can remove the rest of the answer because it's not relevant. And then restate the key points of the linked blog post, as well as your own thoughts, to the answer (because [links *alone* aren't good answers](http://meta.stackexchange.com/q/8231)). –  Sep 18 '12 at 18:30
  • @delnan No - but summarizing a link + including a link **is** a good answer. I think this is appropriate. (I also disagree that the rest isn't relevant. The OP wasn't clear as to "why" being "why was it designed this way" or "why does the compiler complain if I do XXX", too) – Reed Copsey Sep 18 '12 at 18:32
  • 1
    Yes, summarizing a (good) link and including it is a better answer. That wasn't the case when I wrote my previous comment though. I did not remove my downvote yet, because I think the answer as a whole does more harm than good for reasons stated before. As for the relevance of the rest, it seems pretty obvious to me what OP meant. I also refuse to believe that an SO user is not capable of realizing that something is the way it is because someone decided so, for some reasons that made sense to them. Stating that is a mathematician's answer (to borrow a TVTropes term), accurate but useless. –  Sep 18 '12 at 18:38