- "I don't think we should go boldly, I think we should boldly go"
Champion Issue: #5497
Document: https://github.com/dotnet/csharplang/blob/a372f702e6f8f8fbbb0845611715cbfe4450cbd5/meetings/working-groups/extensions/extension-members-unified-proposal.md
Today, we looked through the unified extension proposal to see whether the compiler team can move forward in this general direction. While we're not fully agreed on precise syntax here,
we are agreed that this proposal, and the semantics that it implies, are the way forward for extensions in C#. There are a few things that definitely need to be directly addressed around
the compat story. There was lots of uneasiness about using this as the indicator for backwards compatible generation. Nothing about the keyword implies compatibility, so we think that
it's likely too "cute" and we need a different approach. In particular, there's some thought that we could just always emit in the legacy format, rather than forcing users to understand
how or why they might want to do this.
General proposal is accepted.
Champion issue: #8659
Specification: https://github.com/dotnet/csharplang/blob/a372f702e6f8f8fbbb0845611715cbfe4450cbd5/proposals/dictionary-expressions.md
Open question: https://github.com/dotnet/csharplang/blob/a372f702e6f8f8fbbb0845611715cbfe4450cbd5/proposals/dictionary-expressions.md#question-types-that-support-both-collection-and-dictionary-initialization
Finally, we went over the proposal to add dictionary expressions to the language. Like extensions, we know that there's still plenty of design work to do here, but we want enough of a
specification agreed on that the compiler team can start work and discover the more interesting questions. We spent quite a bit of time on key comparers, and there's clearly more design
work that needs to happen before the LDM is ready to fully approve the direction. We are in general agreement that allowing users to provide a comparer to a dictionary expression is part
of the "minimum required feature set" before dictionary expressions can be shipped; what we're not in agreement about is how we should go about doing that. We brainstormed several different
syntaxes, such as new(...) with [... elements], [.. elements] with (Comparer), [comparer; .. elements], [comparer: comparerInstance, .. elements], and others. Nothing clearly stuck
out as being a preference, so more design will be needed. Additionally, we're unsure whether we should just limit to a key comparer, or whether we should extend to general arguments. For
example, ImmutableDictionary takes both key and value comparers, should we have a way to set both? What about something like HashSet, which isn't a "dictionary"; should there be a way
to provide a comparer to that type? While we don't necessarily think such support is part of a minimum bar, we do want to make sure that we're keeping such support in mind and not designing
something that can't be extended to support these scenarios.
We also took a first look at the question on "hybrid" types, that support both the standard collection expressions and dictionary expression semantics. We are very unsure as an LDM at this point. We don't have good examples of where these patterns might exist, or a good understanding of whether these patterns exist in practice. Therefore, we don't have a good feel for which is generally the more prominent part of such a type's design: collectionness, or dictionaryness. To give the compiler team a direction, we'll start with dictionaryness for now, as there's a very slightly leaning in that direction among LDM members, but we'll definitely need to revisit this in the future.
General proposal is accepted. More work will need to happen on dictionary construction arguments and hybrid type semantics.