LDM Notes for November 20th, 2024

[333fred]

https://github.com/dotnet/csharplang/blob/main/meetings/2024/LDM-2024-11-20.md

Agenda

• Extensions
• Dictionary Expressions

[spydacarnage]

Out of all of those brainstormed dictionary syntaxes, while there isn't a clear winner, I do feel that new(...) with [... elements] stands out as a loser - it doesn't really feel any different from the current syntax except with the added with keyword and changed braces. I agree that being able to specify a comparer in this new syntax is essential, however.

[CyrusNajmabadi]

You can see forms and discussions on this here: https://github.com/dotnet/csharplang/blob/main/proposals/collection-expression-arguments.md

[TahirAhmadov]

I like the [args syntax.

[iam3yal]

Was the following syntax considered? [comparer][.. elements] and I'm not sure about ImmutableDictionary but maybe [key: comparer, value: comparer][.. elements] or just [comparer1, comparer2, ...][.. elements]

[CyrusNajmabadi]

that syntax suffers in that it would break natural types for collection expressions. The first is just a collection expression, with the second being code that indexes into it.

[iam3yal]

@CyrusNajmabadi How about something like this? [(comparer); .. elements], [(key: comparer, value: comparer); .. elements] or you already reached a consensus regarding the need for a keyword?

[CyrusNajmabadi]

How about something like this? [(comparer); .. elements

Mentioned in the linked doc. It means that [(0);(1)] has different meaning from [(0),(1)]. This is incredibly subtle, and would be an easy mistake to make.

[qrli]

[elements...].With(comparer)

[KennethHoff]

There are plans to allow the use of ext. methods on collection expressions, so this would be somewhat ambiguous.

[CyrusNajmabadi]

This has two issues. First, it pulls aspects of the collection out of the [] syntax. Second, it strongly implies that the collection is first constructed, and then transformed, which is not what is going on.

[qrli]

[elements... with(comparer)]

[GabeSchaffer]

It would be nice if there were some way to specify a context to avoid having to put with(comparer) (or whatever the syntax is) in every dictionary expression.

For example, I'd want to be able to say something like this:

with(StringComparer.InvariantCultureIgnoreCase, [
    "en": [ "one": 1, "two": 2, "three": 3, ... ],
    "es": [ "uno": 1, "dos": 2, "tres": 3, ...],
    "it": [ "uno": 1, "due": 2, "tre": 3, ...],
])

instead of something like this:

[with(StringComparer.InvariantCultureIgnoreCase)
    "en": [with(StringComparer.InvariantCultureIgnoreCase)
        "one": 1, "two": 2, "three": 3, ... ],
    "es": [with(StringComparer.InvariantCultureIgnoreCase)
        "uno": 1, "dos": 2, "tres": 3, ...],
    "it": [with(StringComparer.InvariantCultureIgnoreCase)
        "uno": 1, "due": 2, "tre": 3, ...],
])

[BreyerW]

Maybe instead of new syntax make a rule that arguments are inherited in nested dictionaries unless explicitly provided? In other words if u dont want invariant culture in one specific nested level you provide full form in that level and only that.

Theres open question if overriding arguments should override whole inheritance downlevel or only for that specific instance (in this case only top level arguments would spread/be inherited). I can see arguments for both but i think i lean toward overriding inheritance dowlevel atm

[ufcpp]

Should Implicit paramters be reconsidered?

[markm77]

Does the design team still ultimately want extensions that allow adding new interface implementations to existing types? It seems to me adopting the parameter-based receiver approach will make this more difficult in the future (see my comment here). However maybe the design team have another plan?