Type deduction for fields with initializers?

[acaly]

Is there a plan to add type deduction for such types, at least for those with readonly modifiers?

Example: private readonly var list = new SomeVeryLongTypeName<AndSomeGenericParameters>();

Thanks!

[acaly]

I realized this can be simplified with target-typed new, although it might not cover all situations.

[pha3z]

Why not make the inference rule require explicit type declaration when there's anything other than an ordinary literal or new Type on the right side? Or if the issue is just "expressions", then if an Expression is present on the right, require explicit type on the left.

[acaly]

If I understand correctly, fields can be referenced before they are initialized. So the syntax tree might include the type of the field itself. It's even possible that the field type cannot be determined. Local variables does not have this issue because they cannot appear in the expression of its initializer.

This let me realized again how complex is C++...

[HaloFour]

Even without the performance issues the team still believes that the members of the type should be explicitly defined. To make declaration and initialization of these members less verbose in common cases the team instead decided to implement target-typed new. This has the added advantage of being able to be used outside of an initializer.

[CyrusNajmabadi]

Why not make the inference rule require explicit type declaration

1. We effectively did that. With target typed new. So there would be little to no value to doing the 'var' feature when limited to that extent
2. it would still greatly increase the complexity of the compiler because now we'd have a special expression context with a special form of binding, needed only to determine member binding. We have no such concept and would have to build up all the infrastructure for it.
3. definiing "Explicit type declaration". Is not at all clear. Is var v = (int)foo an explicit type declaration? Is var v = x as string an explicit tpe declaration? is var x = int.Parse(...) explicit?

If we did this, there would be a different set of rules for var here, and i don't think that's valuable. Would prefer the current approach which does not encroach on the space for 'var' and which works uniformly everywhere.

[CyrusNajmabadi]

Local variables does not have this issue because they cannot appear in the expression of its initializer.

That's actually not true. See, for example:

            int v = (v = 1) + Foo(v);

            int Foo(int x) => x + 1;

note: please do not write code like this.

[pha3z]

I didn't know about target-typed new. This is brilliant! Solving the problem from the other direction and its actually better! You get the explicitness of the type on the left while eliminating the redundancy. Thank you!

https://www.thomasclaudiushuber.com/2020/09/08/c-9-0-target-typed-new-expressions/