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

[alrz]

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

• Proposal added (below)
• Discussed in LDM
• Decision in LDM
• Finalized (done, rejected, inactive)
• Spec'ed

---

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.