5

I know we cannot do this at class level but at method level we can always do this.

var myList=new List<string> // or something else like this

This question came to my mind since wherever we declare variable like this. We always provide the type information at the RHS of the expression. So compiler doesn't need to do type guessing. (correct me if i am wrong).

so question remains WHY NOT at class level while its allowed at method level

Adam Bellaire
  • 108,003
  • 19
  • 148
  • 163
Prerak K
  • 10,940
  • 7
  • 30
  • 37

5 Answers5

6

There are technical issues with implementing this feature. The common cases seem simple but the tougher cases (e.g., fields referencing other fields in chains or cycles, expressions which contain anonymous types) are not.

See Eric Lippert's blog for an in-depth explanation: Why no var on fields?

Brian
  • 25,523
  • 18
  • 82
  • 173
  • The obvious way to fix the redundancy is, as Eric Lippert's blog mentions, to use [Target-Typed-New](https://github.com/dotnet/csharplang/blob/master/proposals/target-typed-new.md), which is currently in the prototype stage. – Brian Mar 22 '19 at 19:29
5

The compiler guys just didn't implement the support.

It's entirely compiler magic, and the compiler doesn't actually put something into IL that says "figure out the type at runtime", it knows the type and builds it in, so it could've done that for members as well.

It just doesn't.

I'm pretty sure that if you asked an actual compiler guy on the C# compiler team, you'd get something official, but there's no magic happening here and it should be possible to do the same for members fields.

Lasse V. Karlsen
  • 380,855
  • 102
  • 628
  • 825
  • 1
    Yup, it could definitely have been done. I suspect it's not implemented for the sake of readability - limiting the type inference with var to local variables means you only ever see it in the context of its use. – Jon Skeet Oct 01 '08 at 20:00
  • This is incorrect. See my answer. There are technical issues involved. – Brian May 17 '09 at 16:30
1

The var keyword was invented specific to support anonymous types. You are generally NOT going to declare anonymous types at the class level, and thus it was not implemented.

Your example statement

var myList=new List<string>

is not a very good example of how to use the var keyword since it's not for the intended purpose.

Joseph Daigle
  • 47,650
  • 10
  • 49
  • 73
  • 1
    I disagree. It can make code clearer to read by reducing redundancy. See http://csharpindepth.com/ViewNote.aspx?NoteID=61 – Jon Skeet Oct 01 '08 at 20:36
  • While I agree it would reduce redundancy, that is not the reason it was invented. The language designers didn't intend for the keyword to be used that way, and thus wouldn't be used at the class level. – Joseph Daigle Oct 01 '08 at 20:41
  • I just follow this habbit ...since if not doing so, my reharper pluggin wave me a suggestion. – Prerak K Oct 01 '08 at 20:41
  • That note was written by one of the language designers (Eric Lippert). I think it's fair to assume that he believes it's one of the benefits - where the variable's context is visible. It's possible that without anonymous types it wouldn't have made it into C# 3.0... – Jon Skeet Oct 01 '08 at 21:18
  • ... but that's no reason to not reap its benefits in other situations anyway. The bar is set high enough that the benefits of a feature have to be really significant to make it into the language - but benefits which may not be great enough on their own are still worth using when "free". – Jon Skeet Oct 01 '08 at 21:20
0

Pass List Type in Generic

class Class1
{
    public void genmethod<T>(T i,int Count)
    {


        List<string> list = i as List<string>;

        for (int j = 0; j < Count; j++)
        {
            Console.WriteLine(list[j]);
        }
    }
    static void Main(string[] args)
    {
        Class1 c = new Class1();
        c.genmethod<string>("str",0);
        List<string> l = new List<string>();
        l.Add("a");
        l.Add("b");
        l.Add("c");
        l.Add("d");
        c.genmethod<List<string>>(l,l.Count);

        Console.WriteLine("abc");
        Console.ReadLine();
    }
}
Anthon
  • 69,918
  • 32
  • 186
  • 246
0

It's not as simple as implementing var in a method since you also have to take into acccount different modifiers and attributes like so:

[MyAttribute()] protected internal readonly var list = new List<T>();

What I would really have liked is a type-inferenced const!

public const notFoundStatus = 404; // int
Mark Cidade
  • 98,437
  • 31
  • 224
  • 236
  • The attributes and modifiers would have no impact on this as the var is just a placeholder for the type of the expression on the right side of the assignment operator. The compiler just magically substitutes the right type, and it could do that with modifiers just as easy. – Lasse V. Karlsen Oct 01 '08 at 20:36