Championed: Target-typed implicit array creation expression new[]

[alrz]

Allow KeyValuePair<string, string>[] array = new[] { new("key1", value1), new("key2", value2) };

Champion issue: #8993

---

With introduction of new() expression (#100), the following:

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

can be simplified to:

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

but you still need to repeat the type following the field/property initializer. Closest you can get is something like:

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

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),
}

The mechanics of such feature is similar to #2389 or #2460 where there are two source of type inference, the common type and the target-type.

Note: A list/dictionary literal feature would not supersede this proposal because in above examples there's no concrete collection type to infer.

[lcsondes]

Would it not work better to relax the array initializer syntax to allow {{a,b},{c,d}} instead of {new(a,b),new(c,d)} for the KeyValuePair example?

[lcsondes]

I would like if this also included int[] x = new[1];, not just new[]{...}.

[CyrusNajmabadi]

I think this proposal can effectively be subsumed into collection literals.

You would be able to do the following:

KeyValuePair<string, string>[] array = [new("key1", value1), new("key2", value2)];

That solves the array part. KVP is also very special to collection literals so the above could also be shortened to:

KeyValuePair<string, string>[] array = ["key1": value1, "key2": value2];

Note: A list/dictionary literal feature would not supersede this proposal because in above examples there's no concrete collection type to infer.

We support collection/dictionary literals even the absence of a concrete collection type :)

[alrz]

Right, I think it will also work with IEnumerable but only as long as there is a compatible natural type.

IEnumerable<T> x = [value]; // ok; but the target-type (T) won't affect type inference in any ways here.
IEnumerable<T> x = []; // error; no natural type? (is there a default natural type when the list is empty?)
IEnumerable<bool?> x = [true, null]; // error; the most-common-type is `bool` and `List<bool>` fails to assign.

Relates to dotnet/roslyn#37950

[CyrusNajmabadi]

All of the above would be legal @alrz

[alrz]

Great! Though I didn't find anything about a null-aware common type.. does that last example work with var?

[CyrusNajmabadi]

The last example will work with 'var' if 'best common type' is willing to infer bool? for true and null. So we would be gated on that.

[RikkiGibson]

if 'best common type' is willing to infer bool? for true and null.

Unfortunately, I think it is not. SharpLab

[CyrusNajmabadi]

@RikkiGibson right, that's what i'm saying. We're gated on that being a supported concept for c#. the same applies to existing collections today.

[333fred]

When we didn't do that in C# 8, we accepted that it would likely never be done. #881

[audacode]

I opened a discussion thread here: #7175
But closed it once I found this issue..

In short: It is great if this type of syntax will work in C# 12:

Student[] students = [new("John"),new("Jane")];

But we still should have a goal of implementing this feature on the original syntax for the sake of language consistency.

Student[] studentsB = new[] { new("John"), new("Jane") }; // This would ideally work as well.

[CyrusNajmabadi]

I don't believe we need this. You can already write:

KeyValuePair<string, string>[] array = [new("key1", value1), new("key2", value2)];

Spending any effort here would be risky (as it now involves target typing in a scenario that normally uses best-common-typing, and it is subsumed by an existing feature. Any work here would take away from new feature work for areas that would provide much more value. Given that code can move from new[] { ... } to collection exprs, we should consider this space aas already having a better existing solution and consider implicit-array-creation done.

[lcsondes]

@CyrusNajmabadi I agree that collection literals mostly cover the original proposal.* I don't think x = new[1024] is covered, though. That's the main area where I miss this feature, especially for class fields, where I can't var my way out of it.

*I take it back. Dictionary doesn't seem to be covered, either.

[CyrusNajmabadi]

I don't think x = new[1024]

That's an entirely different proposal. Implicit array creation has never supported supplying a length. This request is for target typing the elements. It would not subsume this use case