Feedback on Collection Expressions

[KathleenDollard]

C# 12 introduces collection expressions: https://learn.microsoft.com/en-us/dotnet/csharp/whats-new/csharp-12#collection-expressions

What else would you like to see and what are the important scenarios to you? Dictionaries? Support for var (natural types)?

[GabeSchaffer]

I'd love to be able to use collection expressions to type JSON literals. For example, https://learn.microsoft.com/en-us/dotnet/standard/serialization/system-text-json/use-dom has this sample code:

        var forecastObject = new JsonObject
        {
            ["Date"] = new DateTime(2019, 8, 1),
            ["Temperature"] = 25,
            ["Summary"] = "Hot",
            ["DatesAvailable"] = new JsonArray(
                new DateTime(2019, 8, 1), new DateTime(2019, 8, 2)),
            ["TemperatureRanges"] = new JsonObject
            {
                ["Cold"] = new JsonObject
                {
                    ["High"] = 20,
                    ["Low"] = -10
                }
            },
            ["SummaryWords"] = new JsonArray("Cool", "Windy", "Humid")
        };

but it would be nice to write it as something like this:

        JsonObject forecastObject =
        [
            "Date": new DateTime(2019, 8, 1),
            "Temperature": 25,
            "Summary": "Hot",
            "DatesAvailable": [new DateTime(2019, 8, 1), new DateTime(2019, 8, 2)],
            "TemperatureRanges":
            [
                "Cold": ["High": 20, "Low": -10]
            ],
            "SummaryWords": ["Cool", "Windy", "Humid"]
        ];

[huoyaoyuan]

The interesting thing here is overload resolution between array and dictionary. Is empty collection expression translatable to both array and dictionary?

Is using different brackets for dictionary {} feasible for C#? How should we resolve that for weakly typed data structure?

[CyrusNajmabadi]

Is empty collection expression translatable to both array and dictionary?

Yes

Is using different brackets for dictionary {} feasible for C#?

Probably not. It's too ambiguous with too many other structures (including structures we want in the future)

How should we resolve that for weakly typed data structure?

Collection literals are target typed. So we just use the type your program provides to determine what is being created.

[huoyaoyuan]

Collection literals are target typed.

Use JSON here as an example. JsonNode isn't directly creatable, but it should expose creation from both JsonArray and JsonObject, since it's the element type of them. This can introduce ambiguous for empty collection. Of course new JsonArray or new JsonObject do work here.

[CyrusNajmabadi]

We might consider a syntactic form to state that the result must be a dictionary-type. But it's low on our list of cares currently.

[TahirAhmadov]

Isn't this an API request for the maintainer of the JsonObject class (whoever it is)? If the exposed JsonObject.Add method or whatever takes JsonNode as the second parameter, and said JsonNode has implicit operators from all these primitive types, as well as collection expression surface area of its own, shouldn't the current syntax already support what's requested here?

[DavidArno]

What else would you like to see and what are the important scenarios to you? Dictionaries? Support for var (natural types)?

Yes and yes to dictionaries and var.

Whilst this will introduce a third way of initialising a dictionary, it will be super-nice syntax and is definitely worth doing in my view.

Regarding var, I can see this being a re-run of "even better betterness" continuous improvement process. What I mean by that is that a simple implementation likely will suffice for v1 (maybe just defaults to a struct type if used locally and an IList<T> implementation if passed to other methods/ returned). Over time, the team can then respond to compelling use cases where smarter typing is needed. But there likely is little point in trying to pre-guess what those use cases might be and it likely will evolve over time.

[TahirAhmadov]

I second this and also want to add "forward lookup of collection item type" in the form of var list = []; list.Add(123); where C# determines that list if List<int>.

[TonyValenti]

I want a way to omit null values from my collection expression.

Ie:

var Values = [?x, ?..y];

[thinker227]

You can already do this via a slightly roundabout syntax:

var values = [
    .. x is not null ? [x] : [],
    .. y ?? [],
];

[glen-84]

I'd like to see support for ISet<T>:

Before:

protected static readonly ISet<string> SupportedImageFileMimeTypes
    = new HashSet<string>() { "image/jpeg", "image/png", "image/webp" };

After:

protected static readonly ISet<string> SupportedImageFileMimeTypes
    = ["image/jpeg", "image/png", "image/webp"];

[HaloFour]

See: https://github.com/dotnet/csharplang/blob/main/proposals/csharp-12.0/collection-expressions.md#create-methods

That should allow any type, including interfaces, to declare how they would work with collection literal expressions.

[glen-84]

But ISet<T> is a built-in type, so this still has to be done in the compiler/framework/whatever, right?

[HaloFour]

Yes, it's a type provided by the base class libraries in the runtime so it would be on that team to add support. Here's a relevant comment about ISet<T> specifically:

dotnet/runtime#87569 (comment)

[sab39]

Extension method support (separate from natural type) to allow things like:

public static ImmutableArray<T> AsImmutableArray<T>(this ImmutableArray<T> items) => items;

// consumed elsewhere as
var myImmutableArray = [1, 2, 3].AsImmutableArray();