Proposal: remove the need to explicitly specify the type for initialised fields

[DavidArno]

Currently, C# supports var for local variables, but it is still necessary to specify the type for fields, even if their type could be derived from the initialisation expression.

Allow var and readonly to be used to declare implicitly typed fields:

class C
{
    var _someMap = new Dictionary<string, Func<int>>
    {
        ["foo"] = HandleFoo,
        ...
    };

    static readonly SomeConstant = new SomeType();

    ...
}

As an added bonus, fields initialised by the constructor could have their types inferred too, though this may be tricky to implement in a performant fashion:

[svick]

This is a duplicate of dotnet/roslyn#11551, which was closed by @gafter, who said:

I am not moving this particular issue because I don't have confidence that the LDM would likely consider doing this.

There's also an article by Eric Lippert, who explains the issues with implementing this. (Though the article predates Roslyn, so I'm not sure how much of it is still relevant.)

[jnm2]

I'd be happy with var fields, but only if they come with one of the main benefits of var: forcing immediate initialization. You should never have to scan the entire class or outside the declaration line at all to discover the type of a field (or local). Reading code outside the IDE is a real and common thing.

[DavidArno]

@jnm2,

Fair point. The "added bonus" was a bit of an after thought. Upon reflection, I agree with you that it would be a bad idea. Removed.

[alrz]

What about the other way around (#100),

Dictionary<string, Func<int>> _someMap = new ();

[jnm2]

@alrz That's this: #100

I like choices; I want both. That one is good for when the new() call is in the constructor instead of the field initializer.

[jnm2]

@DavidArno why did you close this? I want it.

[DavidArno]

Ah, I maybe got a bit carried away. I was unsubscribing from threads and closing my issues to allow me a period away from here, with the aim of returning at some point in the future with a more positive attitude. Maybe this one didn't need closing though, so I've re-opened it.

[jnm2]

Thanks man.

[DavidArno]

@jnm2,

Since the opposite proposal (#100):

Dictionary<string, Func<int>>_someMap = new();

is targeted at v8, I'd like to close this one as it's unlikely to ever happen. Do you object?

[jnm2]

Alright, I won't object.

[NetMage]

Closing this makes me sad - I am not sure unlikely to happen is a good reason to lose something people would like to happen just because it might not be in the next version.

[Joe4evr]

@NetMage The main reason that var for fields is so much more unlikely to happen over the target-typed new approach is because it'd make it much too hard for the compiler to detect potential cycles.

Ask yourself: Is it really worth spending many, many man-hours (which then can't be spent on other language features) and increasing the compiler's complexity by that much, when there's a far simpler, far more efficient, near-equivalent alternative on the table as well?