LDM Notes for March 11th, 2024

[333fred]

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

Agenda

• Dictionary expressions

[TonyValenti]

I have long wished that I could use object initializer syntax to set (as opposed to add) elements in a dictionary.

Whatever you decide, I hope you support both.

Also, here is an interesting idea:

What if you could call:
{Object}.Xxx([collectionExpression]);

And that told the compiler to call Xxx / XxxRange for each item/collection in the expression?

[jjonescz]

I could use object initializer syntax to set (as opposed to add) elements in a dictionary.

You can do that via new Dictionary() { ["key"] = value }

[jnm2]

What if you could call {Object}.Xxx([collectionExpression]); And that told the compiler to call Xxx / XxxRange for each item/collection in the expression?

Except in the case of well-known types like List<T> itself, where this difference would not be observable to people writing non-System code, this seems very spooky.

[TahirAhmadov]

It's unfortunate that the "overwrite" semantics were chosen as the default, and that the possibility of supporting both approaches with 2 different syntaxes wasn't even considered.

[CyrusNajmabadi]

and that the possibility of supporting both approaches with 2 different syntaxes wasn't even considered.

That isn't at all what happened. There was lots of consideration and lots of debate on this very point.

[TahirAhmadov]

I can only go off of what the notes have and there is no mention about supporting both semantics in them.
Furthermore, it says

rather than "What is the behavior", we instead want to consider "What APIs are we calling";

This is also not a good sign, IMO - to the extent that some existing dictionary types have inconsistent behavior, we're now tailoring the language to work around those inconsistencies, instead of (what I think we should do) defining a clear and concise set of behaviors and relying on a [DictionaryBuilder] system to make existing types compatible with these behaviors. For example, FrozenDictionary throwing when mutation methods are called is orthogonal to add/overwrite question.

[CyrusNajmabadi]

I can only go off of what the notes have

The nodes didn't say that we didn't consider things. It lists the initial choices we made to start exploring this space. You're inferring that because some initial choices happened that you don't like that that means we didn't thoughtfully consider and debate this space.

The notes are just notes. THey're not a recording, or breakdown of every single second of the meetings. They convey a high level overview of things, and some conclusions.

instead of (what I think we should do) defining a clear and concise set of behaviors

That's not our goal in the collections space. This is not about revamping the ecosystem and moving people to new semantics. This is very much about accepting that collections are everywhere and it's our place to make all of that feel good.

and relying on a [DictionaryBuilder] system

This is again a non-goal (just like with collection-exprs). We are not taking existing types and changing their semantics. Furthermore, we don't want any types to have to update if it can be avoided. The ecosystem should just work here with minimal changes.

This was something we strongly considered important in 12 and which bore out when we went and targeted the vast ecosystem out there.

[CyrusNajmabadi]

This is also not a good sign, IMO

This is the direction we went with collection-expressions initially, and it has worked quite well. It's unclear why this would not be a similarly good approach here. Collection-exprs are, after all, something that is "lowered onto" existing APIs. So defining that lowering is critical here. We want that lowering to be sane, sensible, and intuitive for the ecosystem. We also want it to focus heavily on ensuring that the types of expressions people will want to write will be supported without pain. These aspects helped lead to us deciding to start here and see where it takes us.

Finally, i need to really hammer this home: design is a iterative process. We always go through many rounds of it, and we're constantly taking in feedback and experiences to refine (or upend) our decisions. What's critical though is that we have something we can actually let the ecosystem use to gain that better understanding. Viewing these initial stages as 'wrong' because we didn't try to solve every problem you see isn't constructive here. Perhaps we'll change our minds here. But that will come from solid evidence we get from real world use.

[MgSam]

I still don't get the use case of this feature.

Collection expressions- sure hardcoding any arbitrary type of collection occurs often enough that its own syntax met the bar for inclusion in the language.

But how often are people actually hard-coding dictionaries in their code? I've probably done this a handful of times in my entire career. I don't think this is worth spending design effort on or increasing language complexity for.

[CyrusNajmabadi]

This also comes from the desire to support list/dictionary patterns that have symmetry between construction and deconstruction forms.

Indeed, and slicing/spreading has a very natural correspondence. Both have been super nice to have, and have made lots of code much cleaner in our own codebase.

When it comes to dictionaries, we'll be looking at the corresponding deconstruction form. Though that one will likely be more limited (for example, it seems less likely that we'd be able to effectively support .. var rest).

[MgSam]

We do. :)

Kind of my issue with how the lang design prioritization happens nowadays. Just because something is interesting to the lang team shouldn't be enough to get it into the language. You guys an an unrepresentative subset of the vastly larger .NET ecosystem.

I think it should be data driven- whether that be Github codebases or direct user requests.

As you know very well, no language features are "free"- they all have to be supported forevermore and also add to the mental burden to learn the language. And there's opportunity cost to working on other things instead.

I vastly preferred the "every feature starts at -100 points" method of days gone by where you needed to present compelling user-driven cases to get a feature over the bar.

[CyrusNajmabadi]

I vastly preferred the "every feature starts at -100 points" method of days gone by

Nothing has changed in that regard.

[CyrusNajmabadi]

by where you needed to present compelling user-driven cases to get a feature over the bar.

That work was already done in the original lead up to do collection-exprs in the first place. We're not relitigating that because nothing has changed between now and then. Indeed, the original goal was do this current work as part of the 12 timeframe to begin with. But we cut it out of that release to have some extra buffer time to fit other things in. But the process that led to the decision making on collection-exprs was still done and did already include the work being designed here.

[CyrusNajmabadi]

You guys an an unrepresentative subset of the vastly larger .NET ecosystem.

Language design has always been about doing the work we think has the most value to the ecosystem as a whole. Sometimes that is narrower features which we believe have enormous benefits (often to libraries that will then be consumed by everyone), and sometimes it's QoL features that will hit the vast majority of users. In either event, it's definitely not about serving us. It's about serving the entirety of the ecosystem.

DUs, extensions, collections, etc. all of these are about widespread value to the ecosystem as a whole.