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]

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?

[GabeSchaffer]

The important part of this request isn't that the JsonNode supports collection expressions, but that the C# spec for collection expressions makes that support possible.

This capability will be very useful with JSON APIs.

[TahirAhmadov]

@GabeSchaffer that's the thing - if I'm not mistaken, as designed (proposed) today, C# should support this kind of expression initialization - given the correct public surface area of the types in question.

[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 view forward-looking as valuable because I and probably many others have this very common pattern everywhere:

var list = new List<BlaBla>(); // so tired of typing this out
var list = []; // bingo
while(...)
{
  // ... stuff ...
  list.Add(new BlaBla { ... });
}
// use list for something - return, set property, etc.

[HaloFour]

IMO the rules would end up being ridiculously complicated and run into the same problems of "best common type" that have basically made this inference impractical anywhere else it's been suggested in the language.

[CyrusNajmabadi]

Fwiw, I have a proposal for doing this. I think this is space worth looking into. I think we can find a sweet spot that is not too complex, while also supporting the majority of cases

[HaloFour]

Would that change the conversation around other forms of deferred inference that had been effectively rejected in the past?

[CyrusNajmabadi]

Very likely yes. My proposal is not specific to collection expressions. That said, we might use collections to try out this space before broadening to other types.

[TonyValenti]

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

Ie:

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

[sab39]

For conditionally including single items in a collection expression, how about a suffix ?, as in [a, b?, c]? The usual problem with using ? is ambiguity with existing language syntax, but as far as I can figure out that's not an issue here, because this use of ? would always have to be followed by , or ], neither of which are legal after ? in ternaries or any other existing constructs using ?.

[CyrusNajmabadi]

@sab39 Def an option. I'm also a fan of [ a, b, ? c, ? d]. To keep the sigil near the beginning (like with spreads). We'll def consider several options. And i think the add if not null case is potentially important enough to first-class.

[sab39]

@CyrusNajmabadi I don't want to get too far into bikeshedding a feature that's speculative in the first place (and worth doing no matter what syntax is selected, imo) but I'd like to give my rationale for suggesting ? as a suffix rather than a prefix. It boils down to existing uses of ? in the language, especially the other uses of ? to indicate null-conditional (that is, ??, ?. and ?[]). In each of those cases, the operation is conditional on the thing to the left of the ? being non-null. The other places where ? is used in the language are the ternary operator (again, conditional on the thing to the left of the ?) and when naming nullable value types (where the ? acts as a modifier to the thing on the left of it). So there's a pretty strong precedent in the language for ? as a modifier conditional on what comes before it. I feel like it'd be jarring if in this one scenario only, you look to the right of the ? rather than the left.

[CyrusNajmabadi]

@sab39 understood. And we'd def consider that. IMO, i'd still prefer ? on the left to be in line with ... It too acts on the thing on the right. But no decisions have been made on this and we'll put every option out there for consideration. Thanks!

[TonyValenti]

I prefer it on the left as I feel like it has symmetry with ?.

[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"];

[TahirAhmadov]

@stephentoub how about a flag on the attribute for "static readonly"? Some types get 2 attributes. Then the language can use one of the two strategies where applicable depending on the site

[CyrusNajmabadi]

I woudl be fine with unsorted (as nothing about teh core interfaces indicates it is sorted). I think if we wanted sorted-sets to be something to target, perhaps having an ISortedSet<T> could make sense. So that the api strongly indicates that you do get a set you expect to be sorted.

[KennethHoff]

Speaking of sorted collection interfaces; what about IOrderedEnumerable - does that support collection expressions? What does/would it default to?

[CyrusNajmabadi]

The only interfaces the language supports are those that array implements. Any other interfaces need the `[CollectionBuilder] attribute added to them.

[stephentoub]

what about IOrderedEnumerable - does that support collection expressions?

IOrderedEnumerable is an implementation detail that out of necessity is part of the public API. It's only purpose is to allow ThenBy to be available only after an OrderBy, as otherwise the ThenBy is meaningless. We wouldn't want collection expressions to be able to create an IOrderedEnumerable as doing so would go against its purpose.

@stephentoub how about a flag on the attribute for "static readonly"? Some types get 2 attributes. Then the language can use one of the two strategies where applicable depending on the site

That's adding language and library complexity for something that can more easily be solved just by someone expressing exactly what they want, e.g. typing the field as FrozenSet<T> or adding a cast.

[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();

[BlinkSun]

Dictionary<string, int> d = [ [ "key1", 0 ], [ "key2", 1 ] ];

[jnm2]

@sab39 Looks like we had similar thoughts. #7666 (comment) could easily be extended to support tuples.

[jnm2]

If that's true, what are the odds the BCL team would be open to adding that conversion, and if they did, would the special dictionary syntax even be necessary?

I think we might still want the [a: b] syntax. So far, we're planning it to have overwrite semantics (dictionary indexer calls), not throw semantics (Add calls).

[sab39]

@sab39 Looks like we had similar thoughts. #7666 (comment) could easily be extended to support tuples.

Could it, though? Wouldn't the dictionary type have to implement IEnumerable<ValueTuple<string, int>> for that to be legal?

[jnm2]

It can! Collection initializers have never needed the Add parameter type(s) to match the collection item type. Collection expressions which construct via Add calls are consistent with that.

[jnm2]

Actually, I'm wrong, due to a change in direction that happened very late: https://github.com/dotnet/csharplang/blob/main/meetings/2023/LDM-2023-10-02.md#collection-expressions

The implicit conversion is necessary; collection expressions which construct with Add calls do not support all the scenarios that collection initializers do.

[jnm2]

ℹ️ Until there is actual support for dictionary literals, the following syntax does work (sharplab) for C# 12 so long as you're willing to declare an extension method:

Dictionary<int, string> dict1 = [new(1, "one"), new(2, "two")];
Dictionary<int, string> dict2 = [.. dict1, new(3, "three")];

public static class Extensions
{
    public static void Add<TKey, TValue>(this IDictionary<TKey, TValue> dictionary, KeyValuePair<TKey, TValue> entry)
    {
        dictionary.Add(entry);
    }
}

(Don't worry, this isn't recursive. It binds to void ICollection<KeyValuePair<TKey, TValue>>.Add(KeyValuePair<TKey, TValue> item).)

[vriesdea]

Very nice new method to get clean code!

However, there is one thing in automatic formatting.
Expected:
private string[] PropertyList = ["ClassCode", "CycleState", "DeliveryTimeMax", "Gtin", "Successor"];
But there is sometimes unexpected auto-formatting (position of newlines, space and square brackets) and there not yet options to set in the Formatting options for C# as of Visual Studio 17.8.

[CyrusNajmabadi]

@vriesdea Please file an issue at github.com/dotnet/roslyn. Please provide a full repro if you can. Thanks. :)

[GiottoVerducci]

A way to create ILookup would be appreciated (probably by returning an instance of the internal Lookup class). Currently, the only way to create them is using the .ToLookup() extension method.
I assume that it would probably use a syntax close to the one that will be used for dictionaries.

ILookup<int, string> x = [ 1 => ["a", "b", "c"], 2 => ["d"] ];

[walczakb]

Suggestion 1. Integer range expressions within collection expressions, e.g.:

int[] array1 = [0..n];  // n elements from 0 inclusive to n exclusive
long[] array2 = [0..10, 20..30, 100];  // 21 elements

Here, a..b would be a special syntax in which a and b are target-typed integers. It would not be an instance of type System.Range, so e.g. the ^ operator would not be allowed.

Suggestion 2 (along with suggestion 1). Collection expressions in foreach statements, ideally without the enclosing brackets, e.g.:

foreach (int i in 0..n) { Something(i); }
foreach (long i in 0..10, 20..30, 100) { Something(i); }

Of course, this would be a "collection expression" only when there are at least two elements or a range.

[sab39]

You can get the first part of suggestion 2 quite easily today with an extension method:

public static IEnumerable<int> Each(this Range range)
{
  if (range.Start.IsFromEnd || range.End.IsFromEnd) throw new ArgumentException("...");
  return Enumerable.Range(range.Start.Value, range.End.Value - range.Start.Value);
}
public static IEnumerator<int> GetEnumerator(this Range range) => range.Each().GetEnumerator();

foreach (var i in 0..n) { Something(i); }

Yes, that's technically two extension methods - they could easily be combined of course, but Each() feels useful by itself. For example, it gives a way (albeit a clumsy way) to achieve your suggestion 1 as well:

int[] array1 = [.. (0..n).Each()]; // (0..n).Each().ToArray() would probably be cleaner here
long[] array2 = [.. (0..10).Each(), .. (20..30).Each(), 100];

Long term, the existing proposal for extensions will let you new interfaces to existing types. At that point you can extend Range to directly implement IEnumerable<int>, and get almost the exact syntax you wanted, just with a few extra dots and parens:

foreach (long i in [.. (0..10), .. (20..30), 100]) { Something(i); }

[DavidArno]

I'd love to see both of these implemented. There doesn't seem any real interest in the language team in addressing this missing functionality though.

@sab39, the problem with using extension methods to work around this feature gap is that if (range.Start.IsFromEnd || range.End.IsFromEnd) throw new ArgumentException("..."); line: it's all a bit "hacky" as it fails at runtime, not compile time. Working around that in turn then gets more complex as it needs analyzers that need to be able to check the types used by the start and end values are whole number values, not indexes. It's a achievable, but is far more complex than your initial code.

And as you say yourself, this only achieves a small part of what could be achieved if the C# language directly supported value ranges, rather than the current index-based ranges. As for shapes, extension everything and all those other much promised utopia features appearing before some AI solution takes over the task of writing code, I'm not holding my breath...

[CyrusNajmabadi]

I'd love to see both of these implemented. There doesn't seem any real interest in the language team

This is incorrect. The language team is interested in these cases.

As for shapes, extension everything and all those other much promised utopia features appearing before some AI solution takes over the task of writing code, I'm not holding my breath...

We're currently in the prototyping stage of those features. So it's further along than most other language proposals.

[walczakb]

There is one more natural use case—collection expressions in params, which would basically allow skipping the brackets, e.g.:

Method(0..10, 20..30, 100);

void Method(params int[] args) { Something(args); }

The way params currently works can also be thought of as skipping the brackets (e.g., Method(0, 1, 2) instead of Method([0, 1, 2])), so the above would just make the two features more consistent with each other.

[Tinister]

line.Split([',', ';', '\n'], StringSplitOptions.RemoveEmptyEntries);
// CS0121 The call is ambiguous between the following methods or properties: 'string.Split(char[]?, StringSplitOptions)' and 'string.Split(string?, StringSplitOptions)'

What's the rationale here? Like can a collection expression be assigned to string in any circumstance?

[CyrusNajmabadi]

@TahirAhmadov having string be a supported target type does not mean overloads like this would not work.

I personally never ever had to create a string from a char collection in almost 20 years.

i've def wanted this. but it's mostly just about consistency. in the language, a string is already a collection of chars (and already works with linq/foreach/etc. uniformly like other collections). Having it work as a target just means it works fine in the other direction.

Note: this is not to say that it is equivalent in priority to a char[]/span target.

[TahirAhmadov]

Do you mean that the behavior @Tinister experienced (according to his comment) is an preview bug and that it will work as expected later?

[CyrusNajmabadi]

it is the expected behavior in c#12. we explicitly carved it out so we can make it work in c# 13.

[Tinister]

Why is line.Split([',', ';', '\n']) not ambiguous when line.Split(new char[] { ',', ';', '\n' }) and line.Split(",;\n") are both valid call sites?

[yaakov-h]

@Tinister one is string.Split(char[]) and the other is string.Split(string, StringSplitOptions = StringSplitOptions.None). The overload resolution rules choose Split(char[]) as the better overload rather than using the one with the default parameter, making this non-ambiguous.

[nczsl]

There seems to be a lack of a default type now, consider the following scenario

public class A
{
    public static implicit operator A(int[] source) => throw new NotImplementedException();
    //...
}

// Suppose there's a method accepting an argument of type A
void M(A a) => throw new NotImplementedException();

// Current attempt at calling the method
void M2()
{
    M([1,2,3]); // Produces error CS1503
}

// The correct way to call it currently
int[] x1 = {1, 2, 3};
M(x1); // This works correctly

[huoyaoyuan]

Default type is intentionally not implemented for C# 12. The team is still deciding the correct approach for C# 13.

[CyrusNajmabadi]

Note; this is not really a case of a default type. This is more a case of the language not "seeing through" implicit operators. It's soemthing we could consider, and then you could use collection exprs anywhere where there was an implicit operator and the source-type itself was something that could be constructed by collection exprs.

[nczsl]

Have you considered adding features like 'index functions'? If we have such functions, we only need to provide the expression of this function and the length to construct an array in this form before compilation. However, after compilation, it can be an array with a fixed length and each element is also determined.

[HaloFour]

That feels like a feature much better suited to a helper method or via LINQ, especially since it would be something that could only be evaluated at compile-time in the most limited of circumstances. Collection literals aren't intended to be another form of comprehension syntax.

[nczsl]

/*Of course, we can go further like Python. We can replace the position of "length" with another collection, even if their types are not the same, as long as the index function can calculate it.*/
int[] x1=[i=>2*i,5];
float[] x2=[i=>(i+3)/2,x1]; //ok

[huoyaoyuan]

This is already valid:

int[] x1 = [..from i in Enumerable.Range(5) select 2*i];

[huoyaoyuan]

See #7634

[nczsl]

/*
However, compared to the LINQ expression you provided, my solution obviously has more room for optimization and  performance advantages. Because the context variable 'i' here is directly defined by the array expression environment, and yours is provided by the LINQ extension method, and the extension method is used multiple times from the 'from' clause expansion to 'select' selection, etc. Moreover, I think such syntax is supported by C# after the collection expansion operator, and I don't see anything special about the separate issue you provided; and the index function is a mapping based on array indexing, with clear semantics.
*/
int[] x1 = [..from i in Enumerable.Range(5) select 2*i];
// This can hardly be considered a new proposal because since the expansion operation of '..' no matter what, you can at least do this:
int[] x1 = [..(from i in Enumerable.Range(5) select 2*i).ToArray()]; 
/*
So actually no matter how you write it, as long as it satisfies two points, one, it is an expression, and two, it returns an array. After satisfying these two points, using the expansion operator can make it be constructed into an array; so the existence value of this index function expression I mentioned may not be that high. Although it looks more concise and clear, it is indeed not something completely new that cannot be expressed with old technology. This is also worth discussing and thinking about, to see if there is a need for the index function to exist.
*/

[HeinziAT]

I'd love to be able to use collection expression directly in foreach. Currently,

foreach (string s in ["a", "b"]) { ... }

yields CS9176: There is no target type for the collection expression..

---

Currently known workarounds:

string[] = ["a", "b"];
foreach (string s in values) { ... }

or

foreach (string s in new[] {"a", "b"}) { ... }

---

Notes:

• Making this a language feature would allow the compiler to choose the most suitable/efficient type for "enumerating over".
• There's not many things I miss from VB.NET, but For Each s In {"a", "b"} is one of them. ;-)

[jnm2]

Thanks for the feedback, and great news, work is underway for this!

• https://github.com/dotnet/csharplang/blob/main/meetings/2024/LDM-2024-02-05.md#collection-expressions-inline-collections
• Collection expressions: inline collections in spreads and foreach #7864

[deMD]

One of the things that bug me with collection expressions is the following:

this works var ar = new[] { "string" };
this doesn't var ar2 = ["string"];

If the argument is, because what type should it be if you pass var ar2 = ["string", 1]; I would say the result should be the same as when you do var ar = new[] { "string", 1}; namely that it complains that the best type can't be determined:

[huoyaoyuan]

The question is not about element type, but the container type.

There are different type of collections in .NET. Array, list and spans are all having unique advantages. We didn't have a conclusion to prefer any one.