Champion "Target-typed new expression" (VS 16.8, .NET 5)

[gafter]

Summary: Allow Point p = new (x, y);

Shipped in preview in 16.7p1.

---

• Proposal added
• Discussed in LDM
• Decision in LDM (let's go ahead with prototype)
• Finalized (done, rejected, inactive)
• Spec'ed

See also dotnet/roslyn#35

• https://github.com/dotnet/csharplang/blob/master/meetings/2018/LDM-2018-05-21.md
• https://github.com/dotnet/csharplang/blob/master/meetings/2018/LDM-2018-06-25.md
• https://github.com/dotnet/csharplang/blob/master/meetings/2018/LDM-2018-08-22.md#target-typed-new
• https://github.com/dotnet/csharplang/blob/master/meetings/2018/LDM-2018-10-17.md
• https://github.com/dotnet/csharplang/blob/master/meetings/2018/LDM-2018-10-17.md#target-typed-new

Test plan: dotnet/roslyn#28489

[gulshan]

At least this can be done with object initializers without type-name, which currently generate anonymous types.

[Thaina]

I am more fond of var everywhere instead of empty new

[jnm2]

@Thaina I absolutely agree for locals, but for fields and properties this would actually be preferable to me and a_m_a_z_i_n_g, not gonna lie.

private readonly Dictionary<(Foo foo, Bar bar), List<Baz>> bazByFooAndBar = new();

Love it! Plus also:

private readonly Dictionary<Foo, Bar> barByFoo;

public ctor(IDictionary<Foo, Bar> initialValues)
{
   barByFoo = new(initialValues);
}

I do a lot of field initialization requiring access to this, so I end up saying new and repeating long types quite frequently in constructor bodies.

[Thaina]

@jnm2 Well, readonly in constructor seem great

But still that the only place I think we should do like that, I don't like mutable reference so field should not new anywhere. I wish we could have var field instead

[Richiban]

@Thaina

I wish we could have var field instead

I believe this is a limitation of the fact that C# has a two-pass compiler. The entire signature of a class needs to be known before any of the initialization expressions can be executed, so if you use var for a field the compiler doesn't know the type on the right-hand side of the =.

[alrz]

I think private var fields (and let for readonly) are ok, as long as they are immediately initialized, just like what we have for local vars.

[gafter]

I think private var fields (and let for readonly) are ok, as long as they are immediately initialized, just like what we have for local vars.

@alrz A var-declared local's initialization can only rely on earlier-declared locals. That eliminates the possibility of cycles. Fields do not have any corresponding restrictions that would eliminate such cycles by defining an order in which the types are inferred.

In any case, that would be a completely separate language proposal.

[iam3yal]

Yes please, let's make things less verbose whenever possible and whenever it make sense. :)

[gordanr]

I'm not sure is it related with this topic.

public List<Error> ValidateInput() => new List<Error>();

This piece of code could be, with some generalization, written as

public List<Error> ValidateInput() => new();

I really don't know is it readable and right direction. Possibly not. Just to leave a little note.

[lachbaer]

public List<Error> ValidateInput() => new();

I'm a bit riven by this. On one hand I think that a method's body should be independent of its signature, meaning that the creation of an object for a return should be verbose. On the other hand for expressions, so expression method bodies as well, this is very neat. It's like default vs. default(T), but I think default is valid in block bodies as well?

[masaeedu]

Constructors are kind of useless at the moment, you can't do type inference with them, can't pass a bound constructor as a first class function, etc. etc. At the same time you're stuck using them if you want to use readonly or getter-only properties. The end result is that every class I write has a static "constructor" function that simply delegates to the regular constructor, but behaves like a normal function from the perspective of consuming code.

It would be great if there could be some focus on bringing constructor functions into parity with plain old static methods, instead of piecemeal workarounds like this.

[Joe4evr]

Reading the raw notes:

It may be that there's a subset of the feature that's simpler. We would need that subset to not preclude going further later.

Looking at the concern that an API adding a new overload could break consumers, the "simple" subset of places where target-typed new can be applied (that I'm pretty sure won't preclude further options) would be

• Local variables
• Field/property intializers
• (maybe) return statements

The first two are the places where it seems like most people are really clamoring for it; the last one I just came up at the spur of the moment.

[HaloFour]

@mkane91301

Even if it's not ambiguous to the compiler it's still ambiguous and confusing to the reader. I would find it to be very strange if a target-typed new expression suddenly turned into an anonymous type expression by introducing an overload.

[mkane91301]

@mkane91301

Even if it's not ambiguous to the compiler it's still ambiguous and confusing to the reader. I would find it to be very strange if a target-typed new expression suddenly turned into an anonymous type expression by introducing an overload.

I agree with that. Personally, I would be fine if target-typed new was only supported for initializing fields and properties, which is the only case where you type the same type name twice in a row. I’d be fine with requiring the parentheses. But I think I’ve shown that it’s a small edge case where the compiler could not tell that leaving out the parentheses was a grammatical error for target-typed new and not an illegal cast from an anonymous type. I think it’s reasonable to ask for an improved error message, which was my original point.

[CyrusNajmabadi]

I think it’s reasonable to ask for an improved error message, which was my original point

Definitely. However, improved error messages should be requested at dotnet/Roslyn, not csharplang. Thanks!

[harold-b]

Playing with the preview, I've really enjoyed this feature, thank you.

However, I've missed it when initializing arrays. Are there plans to support target typed new for array types?

I realize I can use Implicitly Typed Array syntax, but this won't work when initializing an array with no initial elements, even if there is an explicit declaration of the target variable type.

It would be useful to have the ability to initialize them as such:

public (float, int, string)[] foo = new [2];

[PathogenDavid]

Are there plans to support target typed new for array types?

It does not appear that there is, from the proposed spec:

• The following kinds of types are not permitted as targets of the conversion
  • [...]
  • Array types: arrays need a special syntax to provide the length.

Arrays are also listed in the 2018-06-25 LDM meeting notes as an unconstructible type.

I agree it seems like arrays should be supported. Based on the wording from the spec, I think it'd be considered to be its own feature separate from C# 9's target-typed new.

[harold-b]

It does not appear that there is, from the proposed spec:

Ah, I missed that document. Thank you for providing the info. I suppose that's that. Hopefully in the future 🤞

[jcouv]

We discussed target-typing for array creation, but in many useful cases it is not trivial to figure out the target element type. For instance IEnumerable<short> array = new[] { 1 };.
Here's the championed proposal: #2701

[lcsondes]

@jcouv If I understand that correctly that's for having new() within new[]{/*here*/}. This on the other hand is KnownType[] arr = new[5];, is that covered?

[harold-b]

@jcouv, understood, looks like there's some design decisions that need to be settled first. Thanks for the example and the link to the proposal.

If I understand that correctly that's for having new() within new[]{/here/}

@lcsondes it looks like both are covered in the linked proposal:

For the sake of completeness, I'd suggest to also make new[] a target-typed expression,

IEnumerable<KeyValuePair<string, string>> Headers = new[]
{
    new("Foo", foo),
    new("Bar", bar),
}

[lcsondes]

What's the plan for new[1]? It doesn't seem to have shipped.

[333fred]

What's the plan for new[1]? It doesn't seem to have shipped.

See #2701.

[lcsondes]

What's the plan for new[1]? It doesn't seem to have shipped.

See #2701.

Thank you, but that only seems to talk about target-typed expressions between the {}. Right now I think the compiler is expecting a , or ] after new[ which would not need a change to cover the examples in #2701 but would need to change to cover new[123]. (see also #100 (comment))

Is this secretly covered? It would be nice if we could get an explicit yes/no.

[CyrusNajmabadi]

I'm not sure what you mean by 'secretly covered'

[lcsondes]

That I do not see a number within square brackets in any of the proposed target-typed new array examples.

[333fred]

That is the proposal I just linked.

[lcsondes]

All I'm trying to get is an explicit yes/no on whether that one covers new[1] specifically, because all it talks about is new[]{new(1)}.

[PathogenDavid]

That is the proposal I just linked.

I think it's something LDM could naturally include alongside that proposal, but unless I'm blind nothing in the #2701 suggests that it would enable something like int[] myArray = new[10]; as an equivalent alternative to to int[] myArray = new int[10]; (Which I believe is what @lcsondes is asking about.)

[CyrusNajmabadi]

We can't give an explicit yes/no since it hasn't been designed yet.

I can say that it would definitely be part of the discussion. However, there's no guarantees that can be given for a future feature that hasn't even been brought to ldm to do.

[julealgon]

@CyrusNajmabadi why is this issue still open and with pending tasks? Hasn't this already shipped some time ago?

Apologies if I'm missing something obvious, but this is not making much sense to me.

[theunrepentantgeek]

Issues are left open until the relevant specs and documentation are fully updated.

[333fred]

That's what the Implemented Needs ECMA Spec label is referring to.