LDM Notes for September 27th, 2023

[333fred]

https://github.com/dotnet/csharplang/blob/main/meetings/2023/LDM-2023-09-27.md

Agenda

• Collection expressions

[TahirAhmadov]

To clarify, will collection expressions have two different sets of rules for System.* namespaces and all other namespaces? If so, I think this is more, not less, confusing. If we want to ensure that collection expressions are rock-solid, why not decorate the "good" methods in BCL and non-BCL collections with special attributes?

[CyrusNajmabadi]

As a language feature, no. The same rules apply. In terms of compiler optimizations, yes. We reserve the right (as we always have) to specialize emit for well known types.

[TahirAhmadov]

I understand that, but even for optimizations, as a matter of simplicity, isn't attribute-driven approach the most straightforward one? If anything, it's probably less work, not more, because 1) finding a method with a specific attribute requires knowledge of one attribute, as opposed to coming up with a list of known types (or criteria to define which type is known), and 2) it takes care of the entirety of this part of the feature in one go, without the need to revisit in a future version. Or am I missing something?

[CyrusNajmabadi]

I understand that, but even for optimizations, as a matter of simplicity, isn't attribute-driven approach the most straightforward one?

That's something we have on our consideration list for later.

it's probably less work, not more,

100% not the case. We'd have to spec out the attribute and actually ship it. Both of which require a lot of work, and then maintaining support. The current approach we have is that we are doing this all as an impl detail, which means we can safely change. Also, it means we can learn and discover from real world request cases to decide waht to do if we want to make this an extensible system for other types to opt into.

--

Finally, think about it this way:

There are good short term designs, and good long term designs. They vary on cost, risk, and capabilities. Often to get the right long term design, you want to play with what you can in the short term space. This is an example of that. The short term design space is low cost, hits a huge sweet spot in terms of bang/buck, and doesn't have risk. Later on though we can expand based on our learnings. The extra time and information will help us design the best public surface area that we then have to maintain forever :)

[sab39]

Does the rule about relying on the implementation details of System.* types allow, for example, treating the [..items] in

IEnumerable<T> DoStuff(ImmutableList<T> items) => [..items];

as a no-op and compiling as if it said => items; instead, since items is of a type known to be immutable?

[CyrusNajmabadi]

Yes it would.