LDM Notes for May 7th, 2025

[333fred]

https://github.com/dotnet/csharplang/blob/main/meetings/2025/LDM-2025-05-07.md

Agenda

• Collection Expression Arguments
  • Interface target type
  • Constructor binding behavior
  • Syntax

[BreyerW]

Before is better, but we don't like the mental stutter that is involved: you start reading an argument list, then see the [ and realize what you read previously were the arguments for a collection expression, not a method call. Inside was the clear winner in our eyes.

i dont quite get this argument, args or with are keywords, not to mention starting with small letters (which is against guidlines for methods in C# anyway) and since they are keywords they get special coloring in IDE further dismantling this argument against before. Also this particular syntax quite closely resembles object initializer syntax, just different brackets which i personally like. new ( ... ) { .... }; vs with ( ... ) [ .... ]; or args ( ... ) [ .... ];

Not that im particularly against inside.

// Already used for main method arguments in top-level statements

This one is unfortunate, especially since top-level statements are newish (so it feels like it robbed us of better fitting syntax, not to mention this feature by virtue of being late-comer isnt all that prevalent in C#). Considering we are literally listing arguments inside this syntax, its strong argument in favor of args, especially since with is used to modify records in nondestructive way which doesnt seems all that connected to collection arguments

; vs ,

I prefer ; cause , looks like what args produces belongs to collection elements which is obviously not true it instead creates underlying object for everything else but isnt collection element and ; makes this unambigious.

[CyrusNajmabadi]

i dont quite get this argument, args or with are keywords

They're just words. You'd have to scan forwards to know if you're actually starting a collection expr or not.

Considering we are literally listing arguments inside this syntax,

Sure. That was a point in favor of 'args'. 'with' also reads just fine as well. It's a collection with these arguments.

At the end fo the day, this will be used in about 1:1000 cases (that's about the rate we see arguments for collections), so it's not like it's going to be hugely important that this keyword be the most perfect thing ever. Both work, and are fine for this specialized, rare, use case.

[CyrusNajmabadi]

and ; makes this unambigious.

This is also an example of something where a user just gets annoyingly poked by the compiler. They'll write with(...), a, b, c and immediately get told "you need to write ; instead". It also leads to an uglier basic form of [with(...);]. In the end, the code will be readable and clear, so trying to avoid any syntactic overlap really isn't necessary.

[BreyerW]

@CyrusNajmabadi

You'd have to scan forwards to know if you're actually starting a collection expr or not.

Not really? Unless you go out of your way to confuse your coworkers by making types or methods or their parameters called the same, args ( or with ( at the start or right after = can be safely assumed to mean collection initializer. ( is enough to disambiguate in typical situations and is right after the keyword (for args the other form is args. and for with its with {. Easy enough)

This is also an example of something where a user just gets annoyingly poked by the compiler. They'll write with(...), a, b, c and immediately get told "you need to write ; instead".

Thats actually a boon? Considering the result of collection arguments does NOT belong to elements. Also as you said yourself its going to be used in 1:1000 cases so this does not need to be perfectly ergonomic, i would posit that reading here is more important and in this space ; is a bit better as it reminds you its not a part of elements

It also leads to an uglier basic form of [with(...);]. In the end, the code will be readable and clear, so trying to avoid any syntactic overlap really isn't necessary.

Cant this requirement be simply dropped when not followed by anything just like you arent forced to write public void Method(string param1,) ? [with(...),] is just as fugly (also this issue disappears by itself when going with before syntax)

[CyrusNajmabadi]

[with(...),] is just as fugly

Then you have the same issue. It's ambiguous with an element.

The point of the discussion was that we want to allow with() to just mean "arguments" without any special syntax to distinguish it from an element.

[BreyerW]

Then you have the same issue. It's ambiguous with an element.

True and for this reason im personally liking before syntax more and more. I honestly think the parse ahead argument would turn up being more theoretical/esoteric than practical in real world apps unless someone can craft or saw in the wild single example to convice me otherwise. Mostly because with() is fairly unlikely to be a type in the wild and while as method is noticeably more likely it would be With() following C# guidlines (and if s1 actually writes with() method, then current syntax of [with(),] also becomes ambigious and even if you decide to highhandedly always parse this as collection arguments in [ ] context, this wont be obvious to s1 who just decides to read it in non-IDE view - like github view or notepad unless they are versed in c# at least a little)

[iam3yal]

I feel like with is a really odd choice because it doesn't really follow this "It's a collection with these arguments" and you're trying to make it readable I mean people will infer the meaning from the context of the keyword and not because of the keyword itself... I really doubt that people will see [with(...), ...] and go oh! "It's a collection with these arguments" not to mention confusing this with the with expression... I really don't get it but we don't really have a choice because it seems like you have decided and to an extent it's disappointing. 🤷‍♂️

[Serdan]

It's not like people have to intuit what it means. You learn it once.

When talking about readability the important factor is that a C# dev can easily parse what the code is doing.

[Tinister]

It seems to gets more readable once you move out of the abstract and look at a concrete example.

"With string comparer ordinal ignore case, "foo" maps to 1, "bar" maps to 2, ..."

[CyrusNajmabadi]

Yup. Looking at the code in practice, things look clear and understandable.

And, based on our actual data, this is a 1:1000 thing for code. Stressing if it feels perfect for you is missing the forest for the trees. It's a simple, effective, syntax that solves the problem with little downside.

That's pretty much it.

[iam3yal]

Maybe it's just me but either way I'll get used to it.