LDM Notes for June 5th, 2023

[333fred]

https://github.com/dotnet/csharplang/blob/main/meetings/2023/LDM-2023-06-05.md

Agenda

• Collection literals

[orthoxerox]

Further, no language that we can find that has dictionary literals differentiates them from collection literals with an extra or different sigil, so there's no prior art to draw on.

ECMAScript?

[333fred]

To be clearer, because I think you might be misinterpreting what my notes meant, we couldn't find a language that used a sigil in addition to the list syntax. Ie, no precedent for the additional modification on the [] we discussed in the notes.

[qrli]

@333fred Thanks for the explanation. But that explanation brings another confusion:
You listed 3 possible options, with the 3rd being simple { }, which is not using a sigil in addition. Then the notes stated "so there's no prior art to draw on. Given this, we don't think there needs to be a separate syntax for dictionary literals". How so? Why does it veto the 3rd option altogether?

[333fred]

Because we simply didn't like it.

[qrli]

I think the syntax affects a bit the perceived behavior on order & duplicate elements.

• When using a different syntax for dictionary, it is a dictionary in and out. It does not preserve order nor duplicate elements.
• When using the same syntax for dictionary as collection/sequence, it feels more like a collection/sequence of key-value pairs, thus preserving order & duplicate elements, until it is converted to a dictionary.

foreach (var kv in ["un" : 1, "deux" : 2, "trois" : 3, "un" : 1])
{
    Console.WriteLine(kv);
}

Of course, this is minor. It is fine to behave whatever you define.

[CyrusNajmabadi]

@qrli We've considered and discussed this. As mentioned, it's not palatable for us. This is esp. true as no good syntax has even been presented that fits cleanly into this space. In our discussions, we've left the door open if someone can think of something. But so far no alternatives have borne fruit.

There are also further costs here if we were to go down that route. For example, a specific 'dictionary' construction syntax would now push us to need a specific 'dictionary' pattern syntax for the deconstruction side of things.

Finally, the above still gets us to a good place where people can consume this feature in a usable fashion in tons of code. If it turns out lots of people are writing the pattern you have above and are feeling like it's a problem, we can address that with a future revision where there is some way to "force" dictionary semantics in the case where List<KVP> might happen and would not be acceptable.

[TahirAhmadov]

I think it would be better to default to dictionary literal if it consists of only spreads and all of them are of type dictionary.

[TahirAhmadov]

OK I see the reasoning here; we want to promise Concat type behavior for this type of spread regardless of list vs dict, and regardless of foreach or var natural type; while reserving the right to optimize inside foreach without changing said behavior.

Really, generic inference would alleviate all these concerns, like if I want to combine dicts into one, I can't do var d3 = [..d1, ..d2]; because d3 becomes List<KVP<K,V>>, and I don't want to type Dictionary<K, V> d3 = [..d1, ..d2];, but at least Dictionary<_, _> d3 = [..d1, ..d2]; would be a little shorter (obviously K and V would be actual types with potentially long names and it's actually less typing and clearer intent).

[CyrusNajmabadi]

but at least Dictionary<_, _> d3 = [..d1, ..d2]; would be a little shorter (obviously K and V would be actual types with potentially long names and it's actually less typing and clearer intent).

Yes. And this is a space several ldm members want to look into in the nearish future.

[jnm2]

Dictionary<.._> 😈

[mungojam]

I can't do var d3 = [..d1, ..d2]; because d3 becomes List<KVP<K,V>>, and I don't want to type Dictionary<K, V> d3 = [..d1, ..d2];, but at least Dictionary<_, _> d3 = [..d1, ..d2]; would be a little shorter

I think the proposals for supporting inference from an extension method after the literal like AsDictionary adds reasonable support for var. It's as long as Dictionary<,> without forcing you to abandon var if that's your style

[TahirAhmadov]

@mungojam actually more like using static My.Helpers.Collection; var d3 = Dict([..d1, ..d2]);

Where Dict is public static Dictionary<K,V> Dict<K,V>(Dictionary<K,V> dict)=>dict;

The problem here is that this will lead to proliferation of various namespace/class/method names for the same thing. It would be extremely helpful if BCL added blessed versions of these, actually.