[Proposal]: Collection Expression Arguments

[CyrusNajmabadi]

Collection Expression Arguments.

• Specification: main/proposals/collection-expression-arguments.md
• Champion issue: [Proposal]: Collection Expression Arguments #8887

Summary

Introduce a way for users to create collection expressions (e.g. [a, b, c]) while also passing along arguments to the respective creation construction for that collection.

An example strawman syntax for this would be:

List values = [args(capacity: 32); a, b, c];

[hez2010]

How about

List<string> s = [a, b, c] where { capacity: 32 };
HashSet<Foo> s = [a, b, c] where { comparer: comp };

?
Unlike with, using where doesn't imply creating/copying the values of the collection multiple times, and it reads intuitively so that developers don't need to check the document to understand what it is.

Asking GPT-4o which one is preferred, and this is the response (click "Details" to expand):

Details

Both designs have merits, but I lean toward the second design for its readability and clarity. Here’s a comparison:

1. First Design:

List<string> s = [args(capacity: 32); a, b, c];
HashSet<Foo> s = [args(comparer: comp); a, b, c];

Pros:

• Explicit separation of configuration (args) and elements.

Cons:

• The args(...) syntax feels unusual and could be misinterpreted as a function call.
• The semicolon separating configuration and elements seems non-standard.

---

2. Second Design:

List<string> s = [a, b, c] where { capacity: 32 };
HashSet<Foo> s = [a, b, c] where { comparer: comp };

Pros:

• where { ... } clearly conveys a configuration block.
• It reads more like natural language and feels declarative.
• The collection's content comes first, making the main focus clear.

Cons:

• Potential confusion if where is used in query languages (like LINQ in C#).

---

Preferred Design:

Second Design (where { ... }) is cleaner and easier to read. It naturally separates the data from configuration details, aligning with modern language design principles like "default-first, configuration-last." This design would likely enhance readability and maintainability in a language's collection initialization syntax.

[siegfriedpammer]

As @jnm2 shows in his example, either keyword might cause confusion and need extra logic in the parser to disambiguate...

Kinda off topic, but honest question, as I have seen this come up in multiple discussions: why are people now asking bulls**t generators, aka LLMs, for their "opinion"?

[hez2010]

why are people now asking bulls**t generators, aka LLMs, for their "opinion"?

LLMs are trained from enormous number of texts gathered from most publishers, public codebase and the Internet, and it predicts the next token from existing tokens based on probability, i.e., it's imitating how it's being trained to speak.
So if a sequence appears many times in the training text, it is more likely to tend to converge to such a sequence when inferring. That's say, by asking LLM you do can know which one does "the texts being fed for training" prefer, and "the texts being fed for training" here come from enormous number of texts gathered from most publishers, public codebase and the Internet, so it's effectively representing how things are being thought by people, at least people who contributed to the training texts.

[333fred]

The LLM failed to notice that, given C# evaluation order, a trailing syntax is likely a non-starter, as that will require us to evaluate all the elements of the dictionary before we can evaluate the arguments.

[siegfriedpammer]

@hez2010 I can - sort of - see your point regarding language statistics, but my experience with LLMs currently is that they produce overly verbose "nice-looking" text that, when I actually read it with the intent of understanding the text and the proposed ideas/concepts, I quickly reach a point where I either feel like my brain cells are vanishing, because it's contradictory or empty/meaningless statements, or I discover that the proposed solution is just plainly wrong/impossible. Especially, when I ask questions about popular programming languages that I am not very familiar with, the code often does not make sense or even doesn't compile and if it does, I check with a colleague, that has expert-level experience in that field and they say it's just plainly wrong/useless.

The point I want to make is that with LLMs it's easy to produce a wall of text that looks nice, but most likely contains a ton of errors and contradictions. This is especially dangerous when designing systems (or in this concrete case: programming languages) where the specification should be clear and precise.

I am not part of the C# LDM or Roslyn and I don't know their position regarding the use of LLMs, but I'd hope that LLM-generated text never ends up in the C# language specification. I also think that when writing proposals the use of LLMs just adds noise to the discussion.

[bzd3y]

Kinda off topic, but honest question, as I have seen this come up in multiple discussions: why are people now asking bulls**t generators, aka LLMs, for their "opinion"?

@siegfriedpammer I'm 100% with you on the sentiment of your question here, however, in this case it seems to have come up with an actual, reasonable, non-bullshit answer.

[iam3yal]

Haven't gave it a lot of thought but have you considered something like [ = (capacity: 32); a, b, c]? args reads well and it does seems like a good candidate but for some reason to me it feels a bit odd.

[HaloFour]

I don't think the colon works for dictionary literals, since they will already use colons. That leaves the semicolon as the only indicator that the first thing is a constructor invocation and not an entry. Although honestly that same problem exists without the colon, just looks like a regular method invocation. :)

[TahirAhmadov]

I don't see a point in adding a colon, either. Halo raises a good point about dictionary literals, too.
args is very clear - the stuff in the following parens goes to the ctor; semicolon for lexical clarity; done.

[333fred]

it reads more like an invocation because that's how you invoke a method or a delegate in the language

That could be a virtue; it is, after all, an invocation of a constructor or builder with these arguments.

[CyrusNajmabadi]

it reads more like an invocation because that's how you invoke a method or a delegate in the language

Right. That's a positive here

[iam3yal]

Alright. :)

[Trarizon]

I hope explicit parameter names can be omitted, so we can keep the expressions simple, like:

[args(32); a, b, c]

and for this reason I don't really like the idea of wrapping arguments in {}, it doesn't look like an argument list when parameter names are left out.

[CyrusNajmabadi]

What follows with/args is just a normal argument list. The use of capacity: was to show that you can provide that, not that it's required

[TahirAhmadov]

Are arguments to builders considered when the type is constructed not using a public constructor?

[TahirAhmadov]

Oops my bad, totally missed it. Thank you

[CyrusNajmabadi]

Why is the builder not used?

Because no one wrote the code to use the builder. Contributions welcome.

Surely it's faster than creating a whole List<> instance and then doing ToArray?

Unclear why that would be. That's all the builder does as well. It makes an growable array, then copies the portion you fill to a new array, and makes an IA out of that new array.

[TahirAhmadov]

I think it's a little safer from maintenance perspective to have IA be generated by its own dedicated builder, and not another, logically unrelated, end-user type. I get your point that today they're essentially identical, but maybe down the line a few ops can be squeezed out of the builder, because of the knowledge of its intended usage?
Anyway, this is a tangent, my main question is answered in the doc, my bad for missing it when I read through it.

[TahirAhmadov]

Staying on that tangent, one last point: this was probably discussed already, but I think it's better for clarity of language-library "interfacing" that we have as few as possible ways to emit the collection expression code; if it has the builder attribute, use that; else, if it has a public ctor and Add method, etc., use that. It looks like the language opted to "special case" IA emitting, which is probably even more work than a standardized builder-attribute approach. I may be wrong, though.

[CyrusNajmabadi]

but maybe down the line a few ops can be squeezed out of the builder, because of the knowledge of its intended usage?

So, that sounds speculative. If there's an actual problem, and the solution is actually better, the investment can be considered. Otehrwise, that's just taking away time and energy from known problems that would benefit from investment.

It looks like the language opted to "special case" IA emitting,

Only because IA has a way to 'take ownership', which is a very uncommon pattern. But the value there was enormous (we measured) and so we did it. That's the fundamental difference. If we can see and measure the improvement, we can consider investing. We're not doing it in a speculative fashion.

[GabeSchaffer]

Has anybody considered using? I know it's already way overloaded (importing namespaces, type aliases, disposable objects) and longer than other suggestions, but it's already a keyword and it makes sense grammatically:
[using StringComparer.InvariantCultureIgnoreCase; "one": 1, "two": 2, "three": 3, ... ]

You could maybe even use it to introduce a scope of sorts, to allow the same parameters to be used for nested collections:

using(comparer: StringComparer.InvariantCultureIgnoreCase)
[   // the inner dictionaries use the same case-insensitive comparer as the outer one
    "en": [ "one": 1, "two": 2, "three": 3, ... ],
    "es": [ "uno": 1, "dos": 2, "tres": 3, ...],
    "it": [ "uno": 1, "due": 2, "tre": 3, ...],
]

[CyrusNajmabadi]

Having the using be outside of the collection expression is a likely non starter due to how ambiguous that is with existing constructs (a using block with a collection expr or attributed construct inside.

Having the using be inside is also not great as it strongly implies disposable resources. Having an expression/statement construct not mean that is likely a non starter

[sab39]

Adding another vote for using inside the expression, despite the association with disposable resources - I feel like "strongly implies" is overstating that association, considering that every C# programmer already knows two completely different meanings for using, only one of which is anything to do with disposable, and is comfortable with the meaning being determined by context. To my knowledge using is never valid in an expression context today so there's no ambiguity and no breaking change.

If it were allowed to be at the end of the expression rather than just at the beginning, and the parentheses were optional if there's only a single parameter, then you get HashSet<string> strs = ["Hello", "World", using StringComparer.OrdinalIgnoreCase], which I think reads pretty nicely!

[CyrusNajmabadi]

I feel like "strongly implies" is overstating that association

I don't. This is esp. true as we've considered using with an expression to exactly mean something related to object disposal.

o there's no ambiguity and no breaking change.

I didn't say there was ambiguity or a breaking change :)

I am saying that i believe this has connotations in the code section (as opposed to the declaration section) which would make this unpalatable. It also blocks of future usage of 'using' to actually deal with object disposal in expression levels.

and the parentheses were optional

This is even worse. See the other thread where i talk about needing to support arbitrary arguments. now we'd have things like:

using ref a, b: c, out d, e, f (ref/out parameters. named parameters. params parameters). This does not look good.

[CyrusNajmabadi]

Note: any solution for arbitrary arguments needs to handle all the facilities we have for arguments today. That means supporting things like ref/out. Supporting named parameters. Supporting params. That's why a syntax that incorporates an argument list is ideal. As that was you get all of that 'for free'.

[iam3yal]

@CyrusNajmabadi I feel like you're pretty satisfied with args but have you considered other keywords besides args? e.g. init?

[CyrusNajmabadi]

Yes. Please see the linked specification. We are open to other keywords there. It doesn't substantively change the core proposal.

[iam3yal]

@CyrusNajmabadi I see how you guys got to args and with and it makes sense and reads great when it's English but in terms of the C# syntax, I don't think that it reads as great as it doesn't follow the same structure, either with or args are the first keyword in the expression so personally I think that init or something similar reads better and a much better fit.

[CyrusNajmabadi]

@CyrusNajmabadi I see how you guys got to args and with and it makes sense and reads great when it's English but in terms of the C# syntax, I don't think that it reads as great as it doesn't follow the same structure, either with or args are the first keyword in the expression so personally I think that init or something similar reads better and a much better fit.

As mentioned, we are open to other keywords. Init will certainly be considered.

[iam3yal]

@CyrusNajmabadi Thank you. :)

[Richiban]

What if we allowed the collection expression syntax as an appendage to new()? E.g.

List<string> items = new (capacity: 32) [1, 2, 3];

[CyrusNajmabadi]

Isn't that why it should be made to work

No. As it would literally break existing code in the while:

i wanna pass ctor args -> user ctor

This feature supports that with with(...).

i wanna use collection expr -> just use after ctor as it was {}

This form is much more verbose, does not work for at leat 5 different areas of collection types and collection building approaches that were in the ecosystem before we created collection expressions.

--

Again, as mentioned in this thread before. We are not relitigating collection-expressions. They shipped several years ago. They unify writing collection values for the vast majority of collection types out there. They are what we are investing in and want to make the go-to for all collection needs (including dictionaries, which are coming in a future release).

[ahmad2smile]

Breaking changes should be ok in an effort to not complicate the language or not to introduce new syntax. Its been done before.

Not to repeat the same argument but with(...) is a new syntax to pass ctor args. A completely new way to do the same thing but slightly differently is not good for a language long term. It might look fancy and fun in isolation of this feature but as a whole it won't turn out well.

[HaloFour]

Breaking changes should be ok in an effort to not complicate the language or not to introduce new syntax. Its been done before.

When worth it, sure. It's not worth it here. This is a question of stylistic preference.

Not to repeat the same argument but with(...) is a new syntax to pass ctor args.

Using new to pass args to a factory method would violate that same principal. That's why the language team chose something generic that can apply to both.

A completely new way to do the same thing but slightly differently is not good for a language long term. It might look fancy and fun in isolation of this feature but as a whole it won't turn out well.

Yet it's how all languages evolve over time, always have and always will. There were plenty of people who complained about the syntax and behavior of language features that you couldn't live without. That is the nature of language design.

[CyrusNajmabadi]

Breaking changes should be ok in an effort to not complicate the language or not to introduce new syntax. Its been done before.

Only for extemely important cases. And when the breaking syntax is the best choice for the feature. In this case, we do not believe this syntax suggestion is better. Indeed, we think it is worse (for reasons already stated). That is it also a breaking change on top of being a worse syntax is the nail in the coffin.

Not to repeat the same argument but with(...) is a new syntax to pass ctor args.

That's not the case. It's syntax to configure the collection. This may be ctor args. It may be be builder arguments. And it may be neither. For example, with dictionary expressions you will be able to do IReadOnlyDictionary<string, int> nameToAge = [with(StringComparer.OrdinalIgnoreCase), "Greg": 21, .. otherPeople]. In this case there is no constructor argument.

A completely new way to do the same thing but slightly differently

it's appropriate here because collection expressions are not simply a replacement for 'new SomeCollection'. They are intended to be a replacement for almost all ways of creating any sort of collection (many of which do not use new X(...) syntax). That's why they use [...] in teh first place. WHich is also a completely new way of doing things. In this world, we want syntax that applies equally well across all collection types, not just the subset you think is most relevant.

It might look fancy and fun in isolation of this feature

The point is exactly to not be fancy or fun. The point is to be effective, and solve the problem well given the myriad design axes that are relevant for collection expressions that have already been stated numerous time @ahmad2smile . We evaluated these other options, and found them severely problematic in other ways. You may disagree with that assessment, but we have to look at the entirety of the design space. Not a cherry-picked subset that some people care the most about. That's what is critical when designing language features that are intended for the entire user-base across nearly all collection scenarios.

[bzd3y]

@ahmad2smile

but with(...) is a new syntax to pass ctor args.

No, it isn't. You're assuming this just calls a constructor, like it is a synonym for new(). It's not (necessarily). That's part of the point (and it took me some thinking to realize that). They can make the compiler compile that with() however they want. So it might need to call a constructor in some situations, but in others they might have it call a type method or extension method. Or both.

For (a maybe contrived) example, that I just made up:

    public class ParityComparer : IComparer<int>
    {
        public override int Compare(int? x, int? y)
        {
            return x % 2;
        }
    }

    public List<int> SomeMethod(List<int> someNumbers, List<int> moreNumbers)
    {
        return [ with(new ParityComparer(), .. someNumbers, .. moreNumbers ];
    }

Might compile SomeMethod to something like this:

    public List<int> SomeMethod(List<int> someNumbers, List<int> moreNumbers)
    {
        List<int> list = someNumbers
            .Union(moreNumbers)
            .OrderBy(x => x, new ParityComparer()).ToList(); // the x => x would come from the compiler knowing to do this for value types
    }

With that they just let you sort that combined list during its production all in one expression. Previously, you would have to build the list and then call Sort or OrderBy on it in separate calls.

One is "Give me a list and then I will sort it."

The other is "Give me a sorted list."

I don't know if they intend, or ever will, to do any kind of merging/splatting of constructors with method calls, but the point is that this is an example of how building collections wouldn't be tied to new().

[dellamonica]

These all look awful in my opinion. Just call the constructor if arguments need to be passed. If you must use the collection expression because it is the shiny new thing, then it could be one of the parameters of the constructor.

I quite like collection expressions and have been using it in my code, but I don't think it needs to fit every scenario.

[TahirAhmadov]

Makes sense. I was thinking if we get rid of using { } for arrays, it can potentially open up other possibilities in the distant future. But that's speculative and I know you don't like that :) Yes I do get suggestions to convert to collection expressions, and one especially amusing/annoying thing is dictionaries, because empty ones are [], but those with values aren't supported yet, I keep thinking, come on, when is this coming already :)

[TahirAhmadov]

In addition to "differing ways of doing the same thing" and "potential future syntaxes with { }", there is one more consideration - don't quote me on this, though - increased compilation speed and reduced Roslyn complexity, those are objective benefits, right?

[dellamonica]

but it gives a sour taste that the code I'm writing today might look just as obsolete in a couple of years.

I can't help with this. We're not aiming for C# to stay the same language as it was in 1.0. I too look at that code and i'm very happy i have much better ways to write things than the forms i was required to back then.

but constantly changing the "modern" way of doing things causes a lot of friction.

So does 'not completing a story'. If we dont' make it so that collection exprs can actually replace existing forms, then you will be required to use M+1 different forms, instead of '1'. Again, i agree with you on a lot of your points. I just think they ultimately lead to entirely different conclusions here. And that because of your same concerns, not doing this feature would actively harm the language.

Yeah, I agree, the feature is good and should be complete. I don't like this syntax, but I don't have anything other than new to offer. So, good luck!

[CyrusNajmabadi]

I keep thinking, come on, when is this coming already :)

C# 14. It's currently being impl'ed in teh compiler as we speak: dotnet/roslyn#76257 :)

increased compilation speed and reduced Roslyn complexity, those are objective benefits, right?

Sure. but that's a tiny benefit to us, but a potential huge hit to the ecosystem for those groups :)

[CyrusNajmabadi]

I don't like this syntax,

The syntax is what we're very much in discussion on. Don't take the critiques on your syntax suggestions to mean we are wedded to one option here. They're merely the same set of lenses by which we're examining all suggestions on the table currently. There are a lot of design considerations here, and finding something that threads that needle is challenging.

So, good luck!

Thanks very much :)

[bzd3y]

The linked design doc discusses the problem with that.

With all due respect, I don't find any of those problems compelling at all. The consistency of the proposal being referred to (new(...arguments...) [...items...]) with the existing syntax easily outweighs any of the problems mentioned. Unless I missed something, there are no technical/mechanical problems with it, right? It seems like the obvious best choice.

To me, options 1 and 2 in that document have the problem of not following existing C# syntax structure (more like python or something), not really being clear and looking like a normal method call (especially in something without syntax coloring) and possibly even conflicting with functions, local functions in particular, with the same name. This is a similar, but maybe less prevalent, problem to using new() to pass in the arguments. It might be rare, but any way to minimize stepping on the developer's toes seems good to me.

Anyway, if the normal new format/pattern is out of the question because the collection initializer must for some reason come first (even object initializers don't?) then I would propose either (or?) of the following:

List<string> items = [1, 2, 3] : new (capacity: 32);
List<string> items = [1, 2, 3] : (capacity: 32); // same, just no `new` if that is considered redundant

To me, that aligns with constructor chaining, which actually seems pretty similar, at least conceptually, to what we are doing here: "Construct a thing with this stuff, but before that, it needs to be initialized with this other stuff."

[CyrusNajmabadi]

it's a common thing that people would choose to hold a collection of arguments.

That isn't relevant here. We can reuse names in new contexts where they do not clash or mislead. Here it would not clash. It's like how we can use using in a statement context vs an import context to mean something different.

[CyrusNajmabadi]

No, they aren't... They are properties of it, 

Properties are part of something. I agree they are not elements. But we think that the things that are part of the collection should be provided within the collection syntax. That way the collection syntax represents the entirety of the collection (properties and elements).

[CyrusNajmabadi]

If something else were used, like ':' (or even ';'

As stated previously, we are considering exactly that.

[CyrusNajmabadi]

clash with dictionary collections that use a tuple for a key?

I was referring to your example where you had (capacity: x): ... within the collection expression.

When you have it outside it clashes with a ternary expression that returns a tuple when false.

[jnm2]

With all due respect, I don't find any of those problems compelling at all. The consistency of the proposal being referred to (new(...arguments...) [...items...]) with the existing syntax easily outweighs any of the problems mentioned. Unless I missed something, there are no technical/mechanical problems with it, right? It seems like the obvious best choice.

@bzd3y I apologize if this has been addressed since I stepped in. The problem with new(...) [expr1, expr2, .. expr3] is that it changes meaning very badly if you add the type name in. So far, any time there's new that once inferred a type, you can also refactor to specifying the type manually. Say, for instance, you're extracting a variable and you prefer var.

[alrz]

What was the argument against extending object intializers with a kvp kind?

new(comparer) {
  "k": v
}

I don't think allowing spread there would be too bad either, actually I would love to see spreads work with anonymous types:

new {
  e.Id,
  .. e.User 
}

That comes in handy in efcore projections, for example.

[CyrusNajmabadi]

What was the argument against extending object intializers with a kvp kind?

new(comparer) {
  "k": v
}

That doesn't help an the existing collection expr types. It also flights against the goal of just having a unified syntax for all collection types.

I don't think allowing spread there would be too bad either, actually I would love to see spreads work with anonymous types:

new {
  e.Id,
  .. e.User 
}

That comes in handy in efcore projections, for example.

This is already an anonymous type.

These syntaxes are also not congruent with collection patterns.

[alrz]

These syntaxes are also not congruent with collection patterns.

I think list/collection patterns are special in that they imply a length match, so if even if you intend to introduce kvp syntax in list patterns, I would expect ["k":v] to match a dictionary with a single key but that's not usually how dictionaries would be used, you most likely be interested on a set of keys, not the total number, and with the discussions around extended property patterns, it seemed to be desirable to enable nesting on indexers {some.prop["k"]:v}. I think indexer/dictionary patterns are more akin to property patterns exactly because they don't require a complete match on the object.

It also flights against the goal of just having a unified syntax for all collection types.

As far as I remember, originally the goal was to have a "dictionary literal" and a "list literal" as two separate concepts, never to unify them, even JS that fundamentally supports both, sees it as two completely different data types. I may go out on a limb to say that a collection of kvps is not by definition, a dictionary.

[CyrusNajmabadi]

I would expect ["k":v] to match a dictionary with a single key

So would I.

but that's not usually how dictionaries would be used, you most likely be interested on a set of keys, not the total number

In that case, a spread can be used to indicate that there can be more items not matches. like ["k": pattern, ..]

As far as I remember, originally the goal was to have a "dictionary literal" and a "list literal" as two separate concepts,

That was not the original goal.

I may go out on a limb to say that a collection of kvps is not by definition, a dictionary.

We do not view a collection of KVPs as a dictionary. A List<KVP<...>> is different than a Dictionary<K, V> and we treat them differently. We do view both as collections. We do not view both as dictionaries.

[CyrusNajmabadi]

even JS that fundamentally supports both, sees it as two completely different data type

I honestly do not understand why JS keeps coming up. We're not designing our collections as JS designed theirs. JS doesn't even have literals for many of their collection types. It's an entirely different ecosystem with a very different approach than what we're doing. Their literals that are even close to ours here only make string-based key mappings. That's just nothing like what we are doing here.

Finally, none of this is relevant in the discussion of being able to provide arguments to collection constructors, factory methods, or interfaces. (Except taht we likely want to be able to provide arguments to dictionaries since they need comparer support). :)

[alrz]

That was not the original goal.

I was referring to dotnet/roslyn#98 where dictionary literals were first mentioned.

[CyrusNajmabadi]

Yeah, that had no impact or bearing on any of the actual design once we started designing it :)

[bzd3y]

I thought I had made another proposal, but it looks like I either didn't submit it or it was deleted (though I see no indication of that and I would think there would be). Hopefully the original really isn't there and I'm not just missing it. So, to attempt to recreate it:

I think this discussion introduces and then leaves out the problem of object initializers with collection expressions. If the goal is to allow constructor arguments (apparently no constructor is ever called, but I don't understand that) with collection expressions, then is the idea that if one wants to use object initialization to set a property on the collection then they are just out of luck?

So maybe if object initializers and collection expressions could be used together and constructor arguments (or whatever they actually are) could be passed into the object initialization then it might help in both cases.

List<int> aList = new()
{
    with(capacity: 32)
}

I initially proposed the object initialization could come after the collection expression, but after seeing comments about how that is problematic, it could just be the other way around.

List<int> aList = // new could be "gone" because we don't like it and it isn't really needed.
{
    with(capacity: 32)
} [1, 2, 3];

// or on one line
List<int> anotherList = { with(capacity: 32) } [1, 2, 3];

Or if we don't like things to be outside, then something like this:

List<int> aList =
{
    with(capacity: 32),
    [1, 2, 3]
};

And the compiler just knows that the bare collection expression inside the object initialization means the list is going to get initialized with that.

Another possibility is to just get rid of the with (optionally, it seems reasonable to allow both forms) and let constructor arguments (or whatever they are) be initialized in object initializations like properties (but keeping : instead of = like normal), where all of these would produce the same result (but maybe differently?):

List<int> aList =
{
    capacity: 32,
    [1, 2, 3] // bare collection would use collection expression initialization (and apparently not a parameterless constructor...?)
};

List<int> anotherList =
{
   collection: [1, 2, 3],
   Capacity = 32
};

List<int> moreList =
{
   [1, 2, 3], // bare collection would use collection expression initialization (and apparently not a parameterless constructor...?)
   Capacity = 32
};

// if a constructor were being called then this would cause an error, but I've been told no constructors are called when creating the list, so maybe this would also be valid.
List<int> tooMuchList =
{
   collection: [1, 2, 3],
   capacity: 32
};

Still another proposal would be that maybe collection constructors, if they are in fact actually being called, could have an implicit collection argument, similar to named parameters for Attributes. So you could do something like:

List<int> aList = new(capacity: 32, [1, 2, 3]);

And then you could just use object initialization below it like you can normally, but the compiler knows you also want the collection built from the expression.

And if the constructor just takes a collection anyway, then the collection expression would just get passed into that so that the collection can do whatever it needs to do with it (which might also solve a problem with some of the other proposals where you could pass a collection in as one of these arguments but then also tell the compiler to build a collection for you).

Both of these proposals would help with situations like in certain frameworks where the objects are containers, and therefore collections of something, but are also objects "first" that have properties other than those they inherit/implement from collections.

An example is Maui and its views. In a situation like that you have to choose between object initialization and collection initialization, and then if your needs change you'll have to switch to the other.

[CyrusNajmabadi]

This was decided before the discussion started, so we're just wasting time aren't we?

No decision has been made. But if alternates are suggested, they're going to be discussed and weighed :-)

[CyrusNajmabadi]

I'll bow out and stop wasting everybody's time.

It's not a waste of time, and you don't need to bow out. :-)

Just know/expect that if alternate proposals are made, that we will discuss them and break down the pros/cons. And we'll definitely bring up if there are major things that would torpedo it.

That's what this site is for, and why we have discussions. But a core part of it is this sort of debate/evaluation :-)

[CyrusNajmabadi]

@bzd3y thanks for the ideas. Based on that, I actually think I'd like to revise the proposal to potentially be:

args attribute_argument_list.

This would them allow: args(namedArg: v1, NamedProp = v2).

Like with attributes, the normal args would be passed along as arguments. Then the NamedProp values would assign to the properties afterwards.

[jnm2]

I feel like attribute arg lists are legacy. I think they might have used { if they had come a little later, and if I remember right, they were made as a concession to the fact that named arguments didn't exist yet. I would very much not like to necromance it now for the first time in our brand new syntax 😄

[CyrusNajmabadi]

I feel like attribute arg lists are legacy. I think they might have used { if they had come a little later, and if I remember right, they were made as a concession to the fact that named arguments didn't exist yet. I would very much not like to necromance it now for the first time in our brand new syntax 😄

Fair. Just a thought on this. But the use cases seem very unlikely here.

[TahirAhmadov]

Actually, speaking of setting properties on collections, it may be better to go with args for the arguments, so that we can use init later for properties, something like this:

ControlList c = [args(capacity: 5); init { RegisterControlsWithContainer = true }; new Button(), new Label(), new TextBox()];
c.Add(new Button());

[jnm2]

Like, this was put up as being open for discussion, but everything is getting shot down by referencing the design requirements. But strict, absolute adherence to those design requirements means there isn't much room for discussion other than maybe deciding between which keyword is used.

Or, maybe we haven't thought of everything, and something else that's out there also fits the design requirements and it remains to be suggested. Or, maybe a great argument can be made to prioritize a different design principle over one that is currently a "requirement." As far as I'm aware, there are no requirements. When syntax is suggested that doesn't follow these priorities, and these priorities are brought up, it doesn't end the discussion, but it does point out that it's time to be weighing priorities themselves, and pointing out tradeoffs. Coming in with a very narrow idea of a particular syntax to suggest, instead of discussing tradeoffs between priorities, isn't likely to add much to the design conversation. That's okay! Ideas are still worth sharing. They don't need to be bulletproof, or even long-lived. But trying to hang onto them after the design priorities are shown to be in conflict with them is probably where people are missing each other.

[CyrusNajmabadi]

I meant for things like questioning the BCL teams implementation of ImmutableArray.

Well, it's shipped. So yes. But many others participated in the design of it originally. And knowing the design concerns that were involved, the outcome is unsurprising.

But that just means it is too late to discuss any constraints there, which means there's only a certain number of possible outcomes. And, again, that's all fine.

It's not to late to discuss design constraints. But it's going to need very strong arguments as these are the constraints the team has already raised as being a top concern. But in many times in the past (every release for certain) design concerns have changed. Heck, on both Extensions/Unions they've changed many times as time goes on. But always with extremely good reasons.

the original concerns seem to win

We literally haven't even brought a proposal to LDM yet. Nothing has 'won'. :)

People can and do get design concerns changed. But expect that to accomplish that that a Very strong argument be made. The design concerns themselves are the results of very strong arguments in their favor, often aligned with the long term design of the lang and a particular feature. Pivoting is very possible, but needs to strongly justify itself.

--

As an example, we pivoted heavily in the design space for extensions exactly because of community feedback and a reformation around a different set of design constraints that helped solve the problems in their own cohesive way that we ultimately liked better. But it was not a trivial change. it took a ton of consideration and weighing between the concerns to ultimately make that switch. And it's uncertain if that won't happen again :)

[CyrusNajmabadi]

Like, ImmutableArray not having a constructor ... doesn't make sense to me. But, oh well.

Well we can discuss that further. But the practical reality is that ImmutableArray does behave the way it does for very good reasons, is a core part of the BCL (and many apis), and has been this way for many years. So our designs have to be thoughtful to ensure they work well with these core types.

If you look at teh original collection expressions specification you'll see that a core motivation is an inclusive design that allows practically all collection types to be used with collection expressions. That core motivation is also one that made the feature palatable in the first place. In other words, the team would not have done collection expressions unless it supported mainline types like ImmutableArray.

and that being literally wrong

So, i would recommend discussing this more with us or hte BCL. Because it's really important to understand why core types work like tehy do. In the case of ImmutableArray it's because it literally is a no-cost wrapper around an array. And when i say 'no cost', i mean it. It was (and still is) critical that ImmutableArray is the same cost as array just safer. If it didn't have the same cost (say, because it actually had a constructor) that would eliminate its usage in perf-critical areas (which would go back to array, and just be unsafe).

[CyrusNajmabadi]

BTW, i think it's fine to have these sorts of discussions here. But you may find something like discord more conducive to it as well.

How are situations where there is a constructor and a create method that take the same/ambiguous arguments? Does the compiler just throw an error for that? Or does it resolve it like it does other similar overload ambiguities?

We don't have any such cases. You could try to build one to see, but it hasn't come up yet as a pattern people use. My guess is that the moment we see CollectionBuilderAttribute we just defer to that over constructors.

Well, my point was that before this discussion I wouldn't have known to do that.

Here's the thing. I think you may be looking at this proposal in a different way than some of us. For most people, this feature won't be relevant. They will just call whatever apis tehy want and will just pass a normal collection-expression with no args in it.

The only reason this feature is relevant is for the users who want to do that, but can't because they do need to pass some special arguments along (like a comparer). These customers will know that they need to do this anyways (and will have been doing it with the existing constructor/create approaches). So they already know this, and so they then go "how do i solve this with a collection exprs?" and they then learn this feature. There isn't a need to go the other direction.

[bzd3y]

Or, maybe we haven't thought of everything, and something else that's out there also fits the design requirements and it remains to be suggested. Or, maybe a great argument can be made to prioritize a different design principle over one that is currently a "requirement."

I get that. I just meant that the requirements are so narrow that it leaves little to be discussed except maybe the keyword that would be used (and even then, now init seems like the obvious choice).

It was (and still is) critical that ImmutableArray is the same cost as array just safer.

I understand. But you still use new for just an array, right? And ImmutableArray does already have an internal constructor. I don't know all the details of the no-cost wrapper stuff. The code is straightforward enough, but I suspect there's some special compiler stuff going on to support it? We don't need to get into all that, I'm only saying that that is why somebody in my position might be confused.

Anyway, I appreciate talking through some of this. I'm on board now.

[TonyValenti]

Looking through this, it looks like we are coming up with a new way of specifying a constructor invocation that may be less succinct and more confusing.

Here are a few thoughts:
Make the constructor args "part" of the type definition:

HashSet<string>(StringComparer.InvariantCultureIgnoreCase) x = ["a", "b", "c"];

Something like this would be really nice when JSON deserialization is involved because it could conceivable also hint the deserializer into constructor args.

Alternatively, the following seems nice to me:

var x = new HashSet<string>(StringComparer.InvariantCultureIgnoreCase)["a", "b", "c",];

Or:

var x = new HashSet<string>(StringComparer.InvariantCultureIgnoreCase){["a", "b", "c",]};

[TahirAhmadov]

#8886 (comment)

[CyrusNajmabadi]

Looking through this, it looks like we are coming up with a new way of specifying a constructor invocation

This is not the case. This is about configuring a collection which handles far more cases than just invoking a constructor.

Here are a few thoughts:
Make the constructor args "part" of the type definition:

This feels like a non starter. The type and the config are separate concepts. The callee defines the type, but the caller defines the config.

Alternatively, the following seems nice to me:

See the design doc for several design concerns this falls afoul of.

[TahirAhmadov]

What about ISet<T> and a comparer?

Maybe a generalized solution is better than special casing IDictionary as the only supported interface.

[CyrusNajmabadi]

I expect we'll make ISet work. Either through special casing, or through CollectionBuilderAttribute.

[OJacot-Descombes]

Collection builder method parameter order.

public static MySet<T> Create(params ReadOnlySpan<T> items, IEqualityComparer<T> comparer = null) { ... }

This could be solved by allowing named arguments after params arguments:

var collection = MySet<int>.Create(1, 2, 3, comparer: new MyIntComparer());

My proposal is to relax the rule that a params parameter must be the last in a parameter list, but then require the first argument after the last params argument to be named at the call site. As an additional effect, this would allow us have more than one params parameter.

[timcassell]

#1458

[jnm2]

Even if this new capability was available, I'm not sure the BCL would add a new overload that simply inverted the order of the parameters.

[CyrusNajmabadi]

This feature has merged into roslyn main branch with: dotnet/roslyn#81924

[TonyValenti]

Hi @CyrusNajmabadi -
Do collection expressions currently work with dictionaries at all? I thought this syntax was already implemented (without comparer support) but I'm having trouble figuring it out and AIs seem to indicate collection expressions for dictionaries are not yet officially implemented.

[CyrusNajmabadi]

They can work if your dictionary exposes an Add(kvp) method.

Nicer support is coming with kvp-elements, which will allow you to write: [k:v]
https://github.com/dotnet/csharplang/blob/main/proposals/dictionary-expressions.md

[En3Tho]

@CyrusNajmabadi Btw have you considered [ expr ](args) syntax? Similar to the usual invocation. E.g. [ 1, 2, 3 ](capacity: 32). Ehat would be the downside of such syntax? Feels quite natural to me at least.

[CyrusNajmabadi]

Btw have you considered expr

Yes. And, like the other options mentioned, it was debated and even mentioned in the specification why we didn't choose it. :)

There are several things undesirable here. In no particular order:

1. You don't even know if or how the collection is configured until reading to the end. Imagine you see this:

HashSet<string> s = [
    // 50 lines of elements
    ](StringComparer.OrdinalIgnoreCase);

This is not great, and takes something very important, and relegates it to a very hard to see/understand position.

2. This is unlike how anyone actually works with collections through any pattern. Configuration is practically always first, and then elements after. So this from a syntax perspective doesn't actually fit the API model that everyone is used to.

3. It pulls the arguments outside of hte collection. Making it hard to tell the actual 'end' or 'span' of the collection value. It's not the final [ it's another scan to find the end of the args.

4. It really is weird from an order of evaluation perspective. You have the args at the end, but they configure teh collection before the elements are added. But in terms of C#, because it's on the right side, it really needs to evaluate after what's on the left. So we'd actually have to evaluate everything (left to right), spilling all the values. Then use the args, then the spilled elements. It's a super weird way to do things in terms of syntax vs how c# normally works, and how it compiles.

THere was a lot going against this form, and it was eliminated due to these issues (among others).

[En3Tho]

Thanks

[cytoph]

As mentioned before, it seems to be too late to do any changes to the syntax, but I really feel the need to ask the question, why it is that with every new C# feature (which is really good for what it provides) the "community" (= the people being active here) decides on a syntax that is sooooo way off of everything else we have in C#, instead of at least trying to keep the language a little more consistent. That makes it really hard for new developers to pick the language up, sometimes even read it - and if C# has one big problem, it's getting people onto our boat.

For this particular case:
We never had arguments/parameters defining the collection that's being created being a part of the collections children/elements list - this is what the syntax states: [with(a, b, c), singleElement, .. collection] looks like some kind of an element being created by using "with", followed by a normal element as well as a collection being spread. Who thought this was the best syntax to use, the clearest and/or most consistent it could be? The comma after "with" makes it look like it's an element. Omitting the comma would make it a little more clear, but it's still inside the collection (= brackets), which doesn't make sense for arguments (not elements) of the collection. Also it introduces a new keyword ("with"; new in this use-case, not new in general in C#) in a syntax we also never had before (at least as far as I know; we had it with curly braces after records to create clones, but I don't think anything like this). I can't imagine (even when looking through this thread) how this was the result the discussion, people that are - as I would imagine - really good at what they do, language design, and so on, came to.

I don't know why in general (not only for this case) we don't create new syntaxes by starting with the full syntax and eliminating unnecessary stuff (for example, as we did by making the type after "new" optional, if the type is defined on the left side of the assignment) until we're left with the absolutely necessary - but it would still be consistent with the existing syntax, and we would still know "where we came from".

A step by step for this feature:

1. Full syntax:
   List<int> list = new List<int>(capacity: 3) { 1, 2, 3 };
2. As this doesn't allow collection expressions, make collection expression work as collection initializers:
   List<int> list = new List<int>(capacity: 3) [ 1, 2, 3 ]; or List<int> list = new List<int>(capacity: 3) [ .. otherCollection ];
3. As was implemented in a previous version of C#, omit the type after "new":
   List<int> list = new(capacity: 3) [ 1, 2, 3 ]; or List<int> list = new(capacity: 3) [ .. otherCollection ];
4. OPTIONAL: if you wanted to, you could omit the "new", but this would not make it clear, which definite type is created, therefore which arguments are valid. But if you can make that clear somehow, then do so:
   List<int> list = (capacity: 3) [ 1, 2, 3 ]; or List<int> list = (capacity: 3) [ .. otherCollection ];

We are left with a short-hand syntax, that still makes it 100% clear, where we were coming from, like what the original is and what has been omitted throughtout the way. And all this without the need to introduce a new keyword or choose a syntax that is so against every existing syntax and only making it less clear for what is asked from the developer.

EDIT 1:
Further, if we, for example, will introduce the possibility to use collection expressions in/as collection initializers (which I think will definitely be needed and come at some time in the future), with this we have two "colliding" (= totally different looking) syntaxes for kind of the same thing:
List<int> list = [ with(capacity: 3), 1, 2, 3 ];
and
List<int> list = new(capacity: 3) [ 1, 2, 3 ];
Try to explain to a new (or even existing) developer why for the latter code (which is a way more commonly seen syntax in C#) the arguments stand in front of (= outside) the collection expression (pretty clear; standard constructor parameters), but for the former they are part (= inside) the collection expression - which does make it really seem like it being an element.

EDIT 2:
Also, not to forget the confusion for these two cases (assuming we have a record type "MyRecord" with a property "Capacity"):
List<MyRecord> list = [ with(capacity: 3), r1, r2, r3 ]; => creates a List with a capacity of 3 and 3 elements (r1, r2, r3)
and
List<MyRecord> list = [ r with { Capacity = 3 }, r1, r2, r3 ]; => creates a List with no specific capacity set, and 4 elements
Two things, doing tooootally different things but still looking very similar in this case.

[CyrusNajmabadi]

Reasoning is given in the design doc for where we landed. However, to go over your points:

Who thought this was the best syntax to use, the clearest and/or most consistent it could be?

The LDM, after much discussion and looking at at least a couple dozen syntax options.

The comma after "with" makes it look like it's an element.

That's correct. And that's how we treat it. An element that 'configures' the collection, just as there are elements that are the data of the collection. We also have elements to spread more elements, and we're going to add a new element to configure keys/values for collections. We may also add an element to conditionally include things (like using ?). We like the having teh complete collection be immediately visible with [ ... ], and that all effects on it are within the braces. It makes it immediately clear you have a collection expression, and it gives you clarity on the entire lifetime of it.

A step by step for this feature:

As this doesn't allow collection expressions, make collection expression work as collection initializers:
List<int> list = new List<int>(capacity: 3) [ 1, 2, 3 ]; or List<int> list = new List<int>(capacity: 3) [ .. otherCollection ];

Right off the bat we have many problems here:

1. The syntax above is already legal and already has meaning.
2. You don't see this is a collection expression without excessive rightward scanning.
3. This doesn't work for interfaces, arrays, spans, or factory builders.

The goal of this feature was to taket he 1% case (where someone wants to configure a collection) and make that easy to do in a lightweight fashion for all collection cases. That step above fails the core goals.

If you wanted to, you could omit the "new", but this would not make it clear, which definite type is created, therefore which arguments are valid. But if you can make that clear somehow, then do so:
List<int> list = (capacity: 3) [ 1, 2, 3 ]; or List<int> list = (capacity: 3) [ .. otherCollection ];

This is a similar problem where this is already legal code with meaning. And people do do things like this (an expression being indexed for some purpose).

This also has enormous problems for user comprehension. (...) is already heavily overloaded in the language. It's a parenthesized expr. It's a cast. It's a tuple. It's a lambda.

In a very real sense overloading more is a significant problem that lowers clarity enormously. It is complex already for both the real shipping parser as well as the mental parser people have to employ in order to determine what their code means. That's a core reason we went with [...]. It means you see the [ and you immediately know you have a collection. You can then trivially tell if you have args in that 1% case just by looking for with. It's that simple.

Two things, doing tooootally different things but still looking very similar in this case.

These look nothing alike to me. One is with(...) and the other is x with { ... }. Those look and feel extremely different, with the only thing in common is a shared keyword. However, the language is replete with examples of reusing a keyword in different locations for different purposes. We aim for these to be syntactically different enough to not cause confusion, and that appears to be the case here as well.

Further, just 'reading' the code gives a very different verbal representation. "Ah, this is a collection with these arguments" vs "Ah, this is a collection, whose first item is this value x that has been with'ed to get a new value". They look and read quite differently.

[cytoph]

First of all thank you for your fast and thorough clarification 🫶

I understand a little more, why it was done this way, but I also get the feeling that one of the core reasons (besides enabling the user to add different "elements" for different purposes) why it wasn't done in a more "consistent" (subjective) way, was that the collection expressions as/in collection initializers with a syntax as I suggested it are "already legal and already [have] meaning" (as you stated).

Maybe I'm just not seeing it, but how are these two already valid C#?
List<int> list = new List<int>(capacity: 3) [ 1, 2, 3 ];
List<int> list = new List<int>(capacity: 3) [ .. otherCollection ]
I know, if you wanted to initialize an array with a set length you can do it like that:
int[] list = new int[1];
But I don't know how the two versions I suggested, would make valid C# code.

EDIT:
Ah okay, maybe I found the specific use-case you meant:
var list = new List<int>(capacity: 3)[1];
var list = new List<int>(capacity: 3)[.. 2];
These two are valid C# and result in either an int or a List<int> variable.
But to be fair: With the "field" keyword, we decided that breaking changes are sometimes inevitable to bring the language forward, and I would say this specific use-case is so uncommon (I can't imagine anyone ever writing this type of code, even in bad code), that it would be feasible to be a breaking change to force either parantheses around or braces after the initializer, to make the new (more commonly used) feature being consistent. So
var list = new List<int>(capacity: 3)[1]; would result in a List with a capacity of 3 but only one element with the value 1.
var list = (new List<int>(capacity: 3))[1]; or var list = new List<int>(capacity: 3) { }[1]; would result in the original behavior (= throwing an ArgumentOutOfRangeException).

[CyrusNajmabadi]

was that the collection expressions as/in collection initializers with a syntax as I suggested it are "already legal and already [have] meaning" (as you stated).

This was a problem with specific syntactic options suggested. However, as mentioned, we genuinely think it's a good and desirable thing for [...] to be the form of all collection expressions. You're free to disagree, but it's a decision we came to after tons and tons of discussion, and it is unlikely to change. As I stated, the spec gives a whole host of design concerns that fed into this.

Another thing to realize, this feature is really the 1:100-1:1000 case. People need to configure collections rarely. We went for something simple and lightweight commensurate with this.

Finally, your syntax does not work for interfaces or factory methods. That's a significant issue for us :-)

--

Wrt breaking changes: we do them sparingly, and only when the value is high enough.

field is a feature we expect people to be using constantly. So we were willing to take the break. That's not the case here. Where even codebases that use CEs are likely to only use this rarely, if not at all. As such, a break is entirely out of the question.

[jeme]

Man I really don't like that syntax, given the ; after the args does break it of a little as opposed to something I just saw demonstrated about this where it was ... = [args(...), 1, 2, 3] which is just awful in my oppinion because:

List<int> opps = [args(capacity: 5), 1, 2, 3];
int args(int capacity) => 42;

List<int> opps = [with(capacity: 5), 1, 2, 3];
int with(int capacity) => 42;

I mean... I don't have an alternative syntax suggestion right now, in the fixed cases we can just stick to:

List<int> list = new (capacity: 3) { 1, 2, 3 };

For now, I know it won't allow expanding, e.g.

List<int> list = new (capacity: 3) { 1, 2, 3, ..other };

Still though... The suggested syntax here seems rushed at this point and should cook for far more time if you ask me.

[bzd3y]

@jeme What are you referring to? This discussion started in December of 2024... So it is over a year old at this point.

To be clear, I'm not a "fan" of this syntax either. But I was also tracking or participating in a lot of the discussion on it within the past year, and am aware that a lot of this was already covered and have also had the opportunity to think about it for some time and realize that there just isn't a perfect solution like we might hope.

Any new keyword is always going to clash with some identifier somebody might have used. And any punctuation or operators or whatever other symbol might imply one thing to one person and something else to another.

If you read some of the old discussion, along with the new, the team working on this, like @CyrusNajmabadi, have considered everything that has been brought up and given their justification on it. And their considerations are deeper than the aesthetics of the syntax, like parser performance.

And my opinnion is that I would rather be without this that having it given the current suggested syntax.

Okay, frankly that is a strange opinion. You don't have to use this... You can just keep using new and you can configure the analyzers to not propose that you change it to a collection expression however you want.

But for now, I have only just seen this proposal and would provide my oppinion.

That's fine. I did too - and it basically aligned with yours. But frankly, these discussions aren't really to get our opinions to make a decision. The decision was more or less already made. The point of these discussions seem to be more just for transparency and then the rare instance of somebody coming up with something that hadn't already been considered that might change the decision.

This isn't a democratic process where we all get to vote on what we like the best, as nice as that might sound (realistically it would be a disaster).

[jeme]

As far as the creation date goes, this is ~1½ month old

The conversation started at least two years ago during the initial conversations around dictionary literals: #8658

And my opinnion is that I would rather be without this that having it given the current suggested syntax.

I guarantee you there were people that said the same thing about features you depend on every day.

It might have started elsewhere, but I think you would have to be an insider to get that, remember that while the .NET team keeps close track of this, the outside people won't. I will bet you that many won't discover such trailing history.

To be fair, my brain is clearly still in 2025, so 1y, 1½ month to be corrected. I really wish there was a better way of discovering these topics somehow, but it's better to voice your oppinion late than never.

[CyrusNajmabadi]

You can just subscribe to this repo. It's fairly low volume. You'll see everything we're designing and thinking about. Our meeting notes are generally up in less than a week after the meeting, and we discuss things vigorously here.

[jnm2]

I will vouch for having personally heard this kind of feedback and really, really pushed for looking for every possible alternative. So far these positions have been thoroughly heard out and included in the balance that led to deciding on the current syntax.

[HaloFour]

It might have started elsewhere, but I think you would have to be an insider to get that, remember that while the .NET team keeps close track of this, the outside people won't. I will bet you that many won't discover such trailing history.

I am one of those "external people". I am probably in the extreme minority in that I have been following since Roslyn was first published on CodePlex and I do have a watch on this repository so I get notifications about everything. I'm not sure what to say about trying to keep these discussions much more public as they are very public now, but there are also a lot of them and they occur over long periods of time.

How did you discover this change now? What would you suggest as a way to advertise and distill down these conversations to casual observers? I expect that the team would appreciate more early engagement by the community.

[CyrusNajmabadi]

which is just awful in my oppinion because:

We looked, and found no one doing this. Which is unsurprising. A method named 'with' is just not a thing that arises in .net.

We also explained in the design spec the problem with semicolon.

It's extremely hard to notice. And having semantics change by a postfix punctuation, just makes understanding a much harder task. Finally, it's a very poor ergonomic experience if you have a collection with no elements in it.

[CyrusNajmabadi]

Well, this is just incidental in this case, right?

No. The language is designed strongly with an eye on the current ecosystem.

This justification couldn't apply in other scenarios.

That's fine. Every feature is evaluated as appropriate based on the circumstances specific to it. This does mean different features will be designed differently. As mentioned in the thread, field is designed very differently than with(...) because there is an entirely different surrounding set of aspects around each.

Well, what about prefix?

We considered, and didn't find any value there. We think with(...) is extremely easy to see and work with as is. So it would just be extra cruft we don't think is necessary. Thanks!

[jeme]

which is just awful in my oppinion because:

We looked, and found no one doing this. Which is unsurprising. A method named 'with' is just not a thing that arises in .net.

We also explained in the design spec the problem with semicolon.

It's extremely hard to notice. And having semantics change by a postfix punctuation, just makes understanding a much harder task. Finally, it's a very poor ergonomic experience if you have a collection with no elements in it.

Its not about the method name, that was just to make the clase very clear, the problem is that the syntax reads like a regular method call, that is my problem with it.

If "With" becomes syntax highlighted in some way, it may help a little, but I am still on the fence, and honestly, I am not seeing the big issue with the current limitations.

[CyrusNajmabadi]

If "With" becomes syntax highlighted in some way

As it is a keyword, it is classified as such.

the problem is that the syntax reads like a regular method call

This is normal in C#. nameof(...) reads liek a method call. typeof(...) reads like a method call. Etc. etc. It's very normal for things to look like method calls. But we recognize and treat many of them as special to the language.

[CyrusNajmabadi]

and honestly, I am not seeing the big issue with the current limitations.

I don't know what this means. :)

[bzd3y]

@CyrusNajmabadi

No. The language is designed strongly with an eye on the current ecosystem.

Of course. I just meant that this would probably be the best choice even if there were a bunch of people with with() methods.

We considered, and didn't find any value there. We think with(...) is extremely easy to see and work with as is. So it would just be extra cruft we don't think is necessary. Thanks!

Well, with as much as I pushed back a few months ago, now I agree with you.

[bzd3y]

@cytoph

I think some others have replied in the time it took me to write this, so hopefully isn't redundant.

the "community" (= the people being active here) decides on a syntax that is sooooo way off of everything else we have in C#, instead of at least trying to keep the language a little more consistent.

I share your concern with language consistency, but a couple of things:

The community as in active people don't make these decisions. The team/collaborators that designs the language makes these decisions.

And as you can see by the discussion above, they had already considered all or most of the things that the rest of the community brought up and had already more or less settled on the path they were taking.

The only reason we get these discussions is in large part for transparency and to provide for the rare instance of where somebody might propose something or raise a concern that wasn't considered.

Point being, it's hard to grasp/accept that this just isn't a democratic process. I know I have trouble with that myself. And as romantic as the idea is, it just isn't realistic. That realistically just wouldn't work. And frankly, in the majority of the rare times where it did, the same concern would still be valid because the majority could just decide on the same kind of inconsistency.

I don't know why in general (not only for this case) we don't create new syntaxes by starting with the full syntax and eliminating unnecessary stuff

I struggle(d) with this too, but it just isn't always feasible or even the goal. None of the options you listed are really "collection expressions" except maybe the last one, but it is pretty vague/ambiguous, both with existing syntax and also just in terms of intent. The others are just essentially object initialization statements that have been abbreviated.

The inconsistency or difference here from existing syntax "is a feature, not a bug". It is the desirable result.

Using collection expressions as an example, think about why we would have them if we already have and can just use new (and I struggled with this and had to think about it for a while). The answer, at least in part, is that new "says" "a constructor is being called" - and it says that strongly, as in, it is explicitly calling the object's constructor.

But what if you don't want to do that? Or maybe more accurately, what if the compiler doesn't want to do that? In other words, that might not be what is happening conceptually or even actually. Obviously a constructor is probably getting called somewhere at some point, because that's what has to happen to create an object. But if the compiler can make intelligent decisions on how to actually produce the collection, then it's not really a good idea to have a developer express that with code that seems to explicitly invoke a constructor.

So these aren't just a shorter way to initialize an object that is a collection. They are a way to abstract away something like collection "allocation" from object creation so that the code isn't locked into/dependent on a specific implementation of a collection and a specific algorithm for producing it.

For example, I used the word "allocation" above, but there might not need to be any allocation caused by the statement, like in the case of something like an array pool where the allocation may have happened "long ago". Or, maybe, multiple allocations are happening for whatever reason, so that new is now misleading because it only implies one when for whatever reason there might be several.

Further examples are just all of the code, methods in particular, used in the production, like static calls, member calls, extension method calls, etc. I.e. your code says new, which normally explicitly indicates the object results from one of its constructors being called when the compiler has actually chained together a bunch of LINQ extension methods to produce the collection result.

with doesn't (have to) imply that a constructor is being called. And it doesn't imply that it isn't. Depending on what the compiler is programmed to do, some of the parameters passed into with could be passed to some other method on the collection. Off the top of my head as a possible example (and maybe it already does this, I don't know), the compiler could be made to look for an IComparer<T> in the with(...) and then depending on what it is doing, it could know to call OrderBy() on the collection before "returning" it, or, say, if it is a List<T> then it could call Sort().

[dotlogix]

I think this feature is doing it in reverse, instead of forcing collection expressions everywhere, just allow spread in object initializers instead like this:

List<int> v = new(10) { ...list1, ...list2 }

This would also allow you to initialize additional other properties using init properties for example:

MyType v = new() { 
    MyProp: "Foo", 
    MyOtherProp: "Bar",
    ...list1,
    ...list2
};

Especially for dictionaries this would be incredibly nice to do it like this:

Dictionary<string, string> v = new(StringComparer.OrdinalIgnoreCase) {
    ...dict1,
    ["MyKey"] = "Foo",
    { "Foo", "Bar"},
 };

Which would translate to:

Dictionary<string, string> v = new(StringComparer.OrdinalIgnoreCase);
foreach(var kv in dict1) {
    v.Add(kv.Key, kv.Value);
}
v["MyKey"] = "Foo";
v.Add("Foo", "Bar")

Or for arrays:

int[] array = new(){ ...list1, ...list2, [2] = 5, [^1] = 9 }

Which would become sth like:

int[] array = new int[list1.Count + list2.Count];
list1.CopyTo(array, 0);
list2.CopyTo(array, list1.Count);
array[2] = 5;
array[array.Length-1] = 9

[CyrusNajmabadi]

The same goes for the index signatures I described, thats also not possible with this proposal as far as I understand how this works

This scenario is being added with dedicated syntax with the dict-expr proposal: https://github.com/dotnet/csharplang/blob/main/proposals/dictionary-expressions.md

You will just be able to say [a: b, .. d, otherKVP].

Regardless, that concern is entirely unrelated to the with(...) feature. with(...) is about configuration. For index/signatures, that's about population.

Like how is this better, less verbose and easier to read: [with(StringComparer.OrdinalIgnoreCase), ..dict2, "MyKey": "Foo", "Foo": "Bar"] Than this new(StringComparer.OrdinalIgnoreCase){ ..dict2, "MyKey": "Foo", "Foo": "Bar" }

It's better for several reasons. First, because i can instantly see that it's a collection expression. Second, because we actively think new is a bad thing for collections. The point entirely is that the collection does not have to, and should not imply that anything 'new' is being created, or have the strong association with new(...) already in the language today (which is calling a constructor). We discussed this deeply and actively felt it was a bad thing that was important to avoid.

at this point you're relitigating collection-expressions entirely. They're done. They shipped. They've been in the language for several years now. We view it as beneficial enough to try to unify the many different ways of creating collections into one single consistent pattern. This includes, but is not limited to:

1. immutable collections.
2. new-able collections.
3. interfaces
4. arrays
5. spans
6. builders
7. dictionaries/kvps (coming in a future version)

All of these needed different ways of initialization, and collection expressions unifies all of them. At this point, we're fully behind them. And we're investing in some areas (like configuration) where there can be some minor friction points for some users.

We're not tossing this aside and trying to get all of the benefits it brings to then port back to new X() { ... } collection initializers.

[CyrusNajmabadi]

Thx @bzd3y that clarified things quite a bit. I am just a bit hesitant adding more and more syntax and features to C#. It has already become quite complex to keep up with all of the changes in C#.

One of the goals of collection-exprs is to actually simplify. It takes 7+ ways of doing things before, and aims to give you one way of doing it. :)

Only thing I might want to add is that personally I don't thing new() is that strange tbh.

That's fine. it's normal in languages that things that some groups care about aren't things you care about. From our perspective, we felt it was very ungood that 'new' would operate in such an inconsistent fashion, especially based on how it has worked in the lang since v1. Totally get that you feel differently, but thems the breaks sometimes :)

In the end it always "creates" something. If the method that gets called and creates an instance is called Create or .ctor doesn't matter for me personally.

It definitely doesn't always create something. That's a main goal of collection expressions, and one of the top reasons we designed it the way we did. We allow the compiler to do practically anything. And this can include never calling 'new', or actually creating something new.

Especially the example shown here like Dictionaries and HashSets you will most definetly create a new instance rather than reusing a pooled version of it,

Sure. But the design is there to work over the wealth of types that are collection-like. We don't want to them diminish the experience for all the other important types, just because it fits better for some types. That's really important to us. We want all of these collections to feel first class, and without oddities like this.

[bzd3y]

@dotlogix

Thx @bzd3y that clarified things quite a bit.

Good, I'm glad.

I am just a bit hesitant adding more and more syntax and features to C#.

I was too. I still am. But "we" shouldn't just freeze the language either, right?

Again, or in case you didn't already see me say this, I was right where you are several months ago when this was being discussed. You can go back up and read me being a pain and imagine @CyrusNajmabadi's finger hovering over a "ban button" or something lol (hopefully not really).

But after they gave all their reasoning and justifications and I had time to think about it, this really does seem like the best path (the only thing I'm not 100% sold on is the , after with(...), but I can look past that).

Only thing I might want to add is that personally I don't thing new() is that strange tbh.
In the end it always "creates" something. If the method that gets called and creates an instance is called Create or .ctor doesn't matter for me personally.

Exactly! And I think that is one of the reasons that they gave you a single concise way to create collections where the compiler chooses the best algorithm to build the collection from the expression you provided.

I guess a another/better way to put it is that new() is for when you do care, or for the people that do care, and want complete control over the algorithm or just want it to be explicit or whatever.

You can still use it if you want. And you can do that, and it causes no problems, partly because it isn't involved here and so there is no way for there to ever be any ambiguity for the compiler or really for a human reader.

Especially the example shown here like Dictionaries and HashSets you will most definetly create a new instance rather than reusing a pooled version of it, so maybe some better examples which are actually not creating instances would be useful to understand the difference.

@CyrusNajmabadi gave you a good example, but at the same time, giving specific examples kind of betrays the point some here, because the point is that this can be designed to abstract any kind of collection in a large number of ways and allow you not to worry about it.

You yourself said that whether it calls a Create or a constructor doesn't matter to you personally, so it doesn't really make sense to ask for an example where it does matter, right?

Looking at it another way, the example given doesn't create an instance now, but what if it did? But that doesn't matter to you, and so you write that code as given in the example. But then they do more work and optimize things so that it doesn't create a new instance. But that doesn't matter to you, right? Well the only reason it doesn't matter to you is because of collection expressions like this, because it means you don't have to change your code.

That could of course still be true with your proposals using new(), but then, as I said, you'd have a new() that created a new instance one minute and then the next minute no longer creates an instance, making new() pretty misleading since there's no new thing produced by the statement. Not only that, but it could also change from one statement to the next in the same code block. Because sometimes it does matter and the developer is going to explicitly use new() to create an instance exactly how they want. Changing new() to mean "I don't care" so the compiler does it for them, or not, based on some possibly subtle syntax would not be a good choice.

[CyrusNajmabadi]

and imagine @CyrusNajmabadi's finger hovering over a "ban button" or something lol (hopefully not really).

Not in the slightest. :)

And we def don't feel that way about any of the feedback given. It's all been in good faith, and it appreciated. We only get out the ban-hammer when customers fall afoul of the .Net community guidelines. Which is usually pretty clear, and only happens when it's consistently happening and the person isn't listening to feedback to tone it down :)

[TahirAhmadov]

Some people said that, the design that was chosen is the best possible compromise, or something to that extent.
I think it's a great design and not at all a "less than ideal compromise". My only "complaint" is, why wasn't this done since the beginning 🤣

[ShawnXu97]

Just some idea maybe it worse but I hope this new feature will be better.

List<int> demo1 = [1,2,3](arg1,arg2...);
List<int> demo1 = [1,2,3]
{
    arg1 = 10;
};

[CollectionArgs(arg1,arg2...)]
List<ing> demo2 = [1,2,3];

[dotlogix]

Unfortunately I think all of these proposals are problematic in one or another way.

Version 1:

List<int> demo1 = [1,2,3](arg1,arg2...);

Pro:

• I like the simplicity of this
• Clear intention
• Enforces the method nature of this feature

Con:

• Readability for long lists
  (Imagine a collection expression with 100+ lines and you have to scroll to the end to see if it uses the correct comparer)
• Inverted order in comparison to the factory method Create(arg1, arg2, ..., elements)
• Arguments are not part of the collection expression itself

Version 2:

List<int> demo1 = [1,2,3] { arg1 = 10; };

Con:

• Mix of object initializers and parameters
• Indicates the creation of an object which is explicitly unwanted by the team
• Arguments are not part of the collection expression itself

Version 3:

[CollectionArgs(arg1,arg2...)]
List<ing> demo2 = [1,2,3];

Con:

• Requires attributes for arbitrary code fragments (very difficult in practice I assume)
• Attributes don't allow non-const parameters
• Attribute syntax is confusing
• Arguments are not part of the collection expression itself

Current Version:

List<int> demo1 = [with(arg1,arg2...),1,2,3];

Pro:

• Easy to read and maintain
• Clear intention
• Enforces the method nature of this feature
• Arguments are part of the collection expression itself
• Clear parameter ordering Create(arg1, arg2, ...elements)

Con:

• New syntax
• Specific & nested keyword placement

Although I personally do not really like this version either, I understand why the team went for this approach over all other existing proposals.

[AlexRadch]

Unfortunately I think all of these proposals are problematic in one or another way.

How about my versions?

Version 4:
List demo1 = [new(arg1,arg2...),1,2,3]; / / I think new(arg1,arg2...) is better than strange with(arg1,arg2...) and args(arg1,arg2...)

Version 5:
List demo1 = new(arg1,arg2...)[1,2,3]; // I like this! But it has conflicts with [] operator.

Version 6:
List demo1 = new(arg1,arg2...).[1,2,3]; // Strange point to remove conflict with [] operator.

[CyrusNajmabadi]

List<int> demo1 = [1,2,3](arg1,arg2...);

As we stated in the proposal:

Does not contort order of operations, especially with C#'s consistent left-to-right expression evaluation ordering semantics. For example, it does not evaluate the arguments used to construct a collection after evaluating the expressions used to populate the collection.

Does not force a user to read to the end of a (potentially large) collection expression to determine core behavioral semantics. For example, having to see to the end of a hundred-line dictionary, only to find that, yes, it was using the right key comparer.

Reads nicely. "This is a collection expression 'with' these arguments, consisting of these elements."

This form falls around of all of these.

[CollectionArgs(arg1,arg2...)] List demo2 = [1,2,3];

This form doesn't even make sense. It would require... attributes? on statements? To control an expression deep within?

`List demo1 = [1,2,3] { arg1 = 10; };

This form violates the need for arguments to come first. It also seems to make them seem as if they were properties... not parameters. Which violates what they actually are (and the need to be able to do all the things that parameters support, like out/ref/etc.).

[AlexRadch]

Version 4:
List demo1 = [new(arg1,arg2...),1,2,3]; / / I think new(arg1,arg2...) is better than strange with(arg1,arg2...) and args(arg1,arg2...)

Version 5:
List demo1 = new(arg1,arg2...)[1,2,3]; // I like this! But it has conflicts with [] operator.

Version 6:
List demo1 = new(arg1,arg2...).[1,2,3]; // Strange point to remove conflict with [] operator.

[CyrusNajmabadi]

List demo1 = [new(arg1,arg2...),1,2,3];

As we stated in the proposal:

[The proposed] syntax was chosen as it: Does not imply calling a new constructor (when that isn't how all collections are created).

Your syntax falls afoul of that.

List demo1 = new(arg1,arg2...)[1,2,3]; // I like this! But it has conflicts with [] operator.

Similarly: "Keeps all information within the [...] syntax. Ensuring that the code still clearly indicates a collection being created. " As well as "Does not imply calling a new constructor (when that isn't how all collections are created).", as well as "Reads nicely. "This is a collection expression 'with' these arguments, consisting of these elements." "

We looked at this, and it just doesn't fit. You don't 'new' up an interface. You don't 'new' up an immutable type or something created with a builder. 'new' has extremely strong conceptual association in C# with a constructor. Whereas collection-expressions are explicitly designed from the ground up to not have that association (given that so many core collections are not 'constructor constructible'). So we did not find this viable at aall.

List demo1 = new(arg1,arg2...).[1,2,3]; // Strange point to remove conflict with [] operator.

Same issue.

In your latter two cases, it is not at all clear that a collection is even being created. That this is happening is only discoverable after a long scan of a potentially unbounded object-creation-expression. And this is highly problematic as object-creation is not how we create collection from C#12 onwards.

[CyrusNajmabadi]

Thank you for the discussion and feedback!

Before proposing alternative syntax, please read the motivation sections of the specification at:

https://github.com/dotnet/csharplang/blob/main/proposals/collection-expression-arguments.md

And please also read through the existing discussions. Many suggestions being posted have already been covered, requiring retreading and restatements of things already clearly in the existing record. The motivation sections explain the design principles, priorities, and careful thinking that went into the syntax. Many of the alternative suggestions being proposed run afoul of the core design constraints that drove the decisions made by the LDM.

Key Design Principles

The syntax chosen ([with(...), elements]) was carefully designed to work well across all collection scenarios:

• Interfaces (like IEnumerable<T>, ISet<T>)
• Constructors (like HashSet<T>(comparer))
• Factory methods and builders (via CollectionBuilder)

It's not acceptable for a syntax to be better for one of these cases at the deep expense of the others. Any viable alternative would need to demonstrate superiority (or at least parity) across all these axes, not just optimize for a single scenario.

For dictionaries specifically: they work with collection expressions today but will be significantly better when dictionary expressions land in a future release. The with(...) syntax will work perfectly there as well, including for immutable dictionaries.

The specification details why specific choices were made around:

• Keeping the collection boundary clear (always within [...] brackets)
• Maintaining correspondence between collection arguments and parameters
• Respecting C#'s strong design of left-to-right evaluation, combined with the fact that virtually all collections provide configuration arguments at the start
• Maintaining readability and consistency
• Ensuring workability across all viable collection types
• Minimizing syntactic overhead

Collection Expressions: The Foundation

The LDM is not relitigating collection expressions themselves. Collection expressions shipped in C# 12 and represent the path forward for collections in the language. The original specification and design thinking can be found at:

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

That proposal reflects the commitment to a readable, minimal, consistent syntax that unified over half a dozen different collection construction forms that existed before. Collection Expression Arguments is a minor augmentation for a very narrow purpose that most codebases will never encounter, and when they do, it should have a very small syntactic price.

This feature is not upending collection expressions or taking things in a radically different direction. The LDM is all in on collection expressions, and everything done in this space will fit well with the [...] syntax that shipped.

The Vision Going Forward

Dictionary expressions (or more precisely, key-value pair elements) are coming in a near future release:

https://github.com/dotnet/csharplang/blob/main/proposals/dictionary-expressions.md

Both that proposal and Collection Expression Arguments demonstrate a consistent vision: ensuring the collection boundary is always clear (within the [...] brackets), easy to read, workable across all viable collection types, and clean and brief. Key-value pairs embody this with just k:v as the element syntax.

These principles will continue to apply to all future work. For example, conditionally added elements (e.g., ? expr in [a, ? b, .. c]) is a potential possibility being looked into, though not something the LDM has committed to yet.

Moving Forward

Feedback on Collection Expression Arguments is welcome, but please:

1. Read the motivation sections of the specifications
2. Review the existing discussions to understand what has already been covered
3. Understand the constraints and design principles
4. Recognize that alternatives would need to be substantially better across all use cases, not just one

The LDM has had extensive discussions and design sessions, and there is an implementation that addresses the core motivations well. For someone who wants to propose changes, it would need to be a substantive proposal, not already mentioned in the existing discussions, that addresses all the core motivations outlined in the specification. This post is being marked as the answer to help provide clarity on the design direction and what informed feedback looks like.