Collection literals are target typed.

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

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.

Isn't this an API request for the maintainer of theJsonObject class (whoever it is)? If the exposedJsonObject.Add method or whatever takesJsonNode as the second parameter, and saidJsonNode 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?

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

This capability will be very useful with JSON APIs.

@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.

I view forward-looking as valuable because I and probably many others have this very common pattern everywhere:

varlist=newList<BlaBla>();// so tired of typing this outvarlist=[];// bingowhile(...){// ... stuff ...list.Add(newBlaBla{ ...});}// use list for something - return, set property, etc.

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.

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

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

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.

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?.

@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 theadd if not null case is potentially important enough to first-class.

@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 theleft 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.

@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!

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

@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

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 anISortedSet<T> could make sense. So that the api strongly indicates that you do get a set you expect to be sorted.

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

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

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 asFrozenSet<T> or adding a cast.

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

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 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 implementIEnumerable<ValueTuple<string, int>> for that to be legal?

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.

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 donot support all the scenarios that collection initializers do.

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

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

publicstaticIEnumerable<int>Each(thisRangerange){if(range.Start.IsFromEnd||range.End.IsFromEnd)thrownewArgumentException("...");returnEnumerable.Range(range.Start.Value,range.End.Value-range.Start.Value);}publicstaticIEnumerator<int>GetEnumerator(thisRangerange)=>range.Each().GetEnumerator();foreach(variin0..n){Something(i);}

Yes, that's technically two extension methods - they could easily be combined of course, butEach() 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 herelong[]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 extendRange to directly implementIEnumerable<int>, and getalmost the exact syntax you wanted, just with a few extra dots and parens:

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

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 thatif (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...

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.

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

Method(0..10,20..30,100);voidMethod(paramsint[]args){Something(args);}

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

@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.

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

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

Why isline.Split([',', ';', '\n']) not ambiguous whenline.Split(new char[] { ',', ';', '\n' }) andline.Split(",;\n") are both valid call sites?

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

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

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.

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.

This is already valid:

int[]x1=[..fromiinEnumerable.Range(5)select2*i];

See#7634

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

The question is not aboutelement type, but thecontainer 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.