[Proposal]: Collection Expression Arguments

[CyrusNajmabadi]

Collection Expression Arguments.

• Specification: https://github.com/dotnet/csharplang/blob/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<string> 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):

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]

The linked design doc discusses the problem with that.

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

Something like a tuple being <value1, value2, value3> could work just as well and doesn't conflict with something like parameter lists.

Sure. But then it would conflict with future proposals if we want to use that for something else (like generic lambdas).

We believe the tuple syntax is what we want. But yes, that tuple syntax then restricts using that same syntax to mean something else where tuples would be legal. That's language design. When you carve out syntax for some purpose in some context, you cannot use it for something else.

I'm not sure why/how this is relevant. Tuples shipped years ago. We like the syntax for them. We're not changing their syntax. So we cannot use syntax that clashes with them.

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

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

[CyrusNajmabadi]

I might guess we might do things like attributes, where you can have named arguments and named properties. :-)