Proposal: var class member when using auto-completion

[dieterb0hlen]

Summary

Possibility to use var on class members and properties when using auto-implementation.

Motivation

Less typing and shorter lines in class declarations.

Design

class MyClass
{
        private ConcurrentDictionary<float, decimal> _dict = new ConcurrentDictionary<float, decimal>(); // currently
        var _dict = new ConcurrentDictionary<float, decimal>(); // proposal
}

[theunrepentantgeek]

Variations of this has been suggested many times - for fields, methods, properties, etc - but I'm having trouble finding references to the duplicates - var, field and member are very commonly used.

The approach being taken by the LDM - and currently scheduled for C# 8.0 - is called Target-Typed new() #100.

class MyClass
{
        private ConcurrentDictionary<float, decimal> _dict = new();
}

[Austin-bryan]

@SymmetryKeeper-Y From what I understand, this isn't just a design choice, but it is impossible to not use var at the class level for some reason. You can read more about it here as well as the links in that post. Basically it will involve rewriting the compiler and you're asking the compiler to consume type information while it's still generating that information, which can't be done.

Remarkable that for some specific cases...

Not really. And new() isn't just to use for null checking or initializing fields. You can use it like this:

public void DoSomething(Dictionary<string, int> dict) { ... }
...
DoSomething(new());

And your code only works with parameterless constructors which is, like you said, "some specific cases". With new() you can also pass in the arguments needed, allowing you to do stuff like:

public Foo { get; set => field = value ?? new(bar, baz); }

To make sure Foo is never null.

[HaloFour]

@willard720

From what I understand, this isn't just a design choice, but it is impossible to not use var at the class level for some reason.

As described to me on Gitter the issue lies largely in how Roslyn was implemented as a concurrent and non-blocking compiler allowing multiple threads to query into the semantic model simultaneously with the expectation that they would each get back consistent results. That makes it difficult to make the kind of circular inferencing detection mechanism that var at the class level would allow. Not impossible, just challenging and expensive from an effort point of view, but that cost would weigh into the decision as to whether the feature was worth implementing.

[CyrusNajmabadi]

Not impossible, just challenging and expensive from an effort point of view, but that cost would weigh into the decision as to whether the feature was worth implementing.

Exactly. IMO, fields would definitely be doable, but would have engineering challenges associated with them. @gafter would understand the details the best.

The part that gets into "super complex, to the point that it's highly unlikely it could ever warrant the costs" is if you wanted "var" return types for methods. With how methods interact with inheritance/implementations, it becomes super complex that figuring out signatures of methods now involves needing to understand bodies (which also need to deeply understand the inheritance/implementation shape of their surrounding type).

--

My personal opinion though is that it's more desirable to have target typed new than var fields. Target-typed-new addresses a broader set of language cases, and introduces less restrictions. For example, with target-typed-new, i can write private SomeType field = new (...); or private SomeType field; public MyType() { field = new (...); }. I'm not limited to the constraints 'var' usually has wrt the type and the initializer.

[Austin-bryan]

@SymmetryKeeper-V
Well, the name of the method should make it obvious what the type is. For example, OpenDocument(new()). Safe to assume I'm creating a new Document here and not a new Person.

Also, couldn't you say the same thing about using numbers or bool flags in general? DoSomething(54, false, true, false) is currently allowed, though it's very confusing. That's why we have named parameters. So we could have something like this:

SetDogAge(new AgeMeasuredInDogYears(5));
SetDogAge(age: new(5));
SetDogAge(new(5));

Given the method age, it's pretty clear, and we can still add the parameter name to better explain what's going on. Frankly, I think we should care more about people using IDE's that can show that information, as that's where code is viewed most often. Besides that, anywhere online, StackOverflow, online blogs, or textbooks are either to likely not use it, or show the method decleration as well that shows the type of the argument. They usually already have that context.

And if it's really that confusing then they just won't use it. Why should we have to not allow a feature just because some dude might write a blog and use that feature and it's a tad bit more confusing?

[jnm2]

@willard720 That's a great argument. I use named arguments all the time already, and new() would allow me to continue preferring parameter names over specifying types in more places.