Eyeball Ergonomics - var for fields

[TonyValenti]

I've recently noticed that VS is recommending C# codefixes that convert code like:

private SemaphoreSlim EnsureCollectorAsync_Lock = new SemaphoreSlim(0, 1);

into:

private SemaphoreSlim EnsureCollectorAsync_Lock = new(0, 1);

I wanted to pass some thoughts about this form.

I don't like it because I feel as though my eyes have to jump between the first part of the line (SemaphoreSlim) and the last part of the line (new(0, 1)) to know what is being created. One of the reasons I like the syntax:

var EnsureCollectorAsync_Lock = new SemaphoreSlim(0, 1);

Is I feel like it groups the type definition and its value initialization together.

Today, var works for variables. Can it be expanded to work with fields too?

[HaloFour]

Today, var works for variables. Can it be expanded to work with fields too?

The team has stated on several occasions that they are not interested in extending type inference to fields or other members. Apart from the desire to keep the contract explicitly it would also drastically change the performance characteristics of the compiler since the type of members could not be known unless the initializing expression is evaluated which could reference other members and so on.

https://blogs.msdn.microsoft.com/ericlippert/2009/01/26/why-no-var-on-fields/
dotnet/roslyn#5168
dotnet/roslyn#17 (comment)
#2996 (comment)

[alrz]

I think if we get property-scoped locals (#133) it would make sense to extend it to the outer scope: type-scoped locals.

Therefore all these would be true:

• Can use var if initialized.
• Cannot specify accessibly modifiers.
• Cannot use static (unless we also have static locals).
• Cannot use readonly (unless we also have readonly locals).

A lot of questions around syntax/semantics must be resolved for property-scoped locals, all of which will apply here as well.

[CyrusNajmabadi]

i would not go for type-scoped-locals as the overlap with fields would just be strange and confusing for most.

[alrz]

The above definition (assuming we will have static/readonly locals at some point) would only enable var vs. regular fields.

I think the exclusion of access modifiers from such decls (which is not new for locals anyways) should resolve any possible confusion about what's possible.