C# Language Design Meeting for September 21st, 2022

Agenda

• Unchampioned issue triage
  • Track subtype exhaustiveness for classes with only private constructors
  • ReadOnlySpan initialization from static data
  • Embedded Language Indicators for raw string literals
  • Implicit Parameters
• Unsafer Unsafeness
  • Conclusion

Quote(s) of the Day

• "Yeah, I'm only hearing positive reactions, I've got to shoot it down"
• "Unsafer unsafeness"
• "It's like a horror movie. It's terrifying, but you want to go see it, because it's also amazing."

Discussion

Unchampioned issue triage

Track subtype exhaustiveness for classes with only private constructors

https://github.com/dotnet/csharplang/issues/4032

This comes up often in the context of discriminated unions. It should be thought about when designing that feature. There are some potentially interesting cases in this with ref assemblies as well, since private constructors are normally dropped. Into the working set.

ReadOnlySpan initialization from static data

https://github.com/dotnet/csharplang/issues/5295

We like this idea. Into the working set.

Embedded Language Indicators for raw string literals

https://github.com/dotnet/csharplang/issues/6247

We intentionally left the door open for this proposal, but we'd like to design for more than just raw string literals. We're uncertain whether just multiline strings provides a generalized-enough benefit beyond the existing comment format. Into the working set with this caveat.

Implicit Parameters

https://github.com/dotnet/csharplang/issues/6300

This community proposal is inspired by features from other languages, like implicit parameters in Scala 2. While we think the space is interesting, we think there's several potential issues: first, Scala 2's implicit parameter support was not well received, and reworked as part of Scala 3. The way that binding worked in Scala 2 caused a number of understandability issues, and we don't want to repeat them in C#. Kotlin is also adding a similar feature, context receivers, and we'll be interested to see how it is received by that community. We're also not certain of how widely this would be adopted, especially in the BCL. Finally, there is significant negative community sentiment on the issue. This will go into the backlog for now, pending further community requests.

Unsafer Unsafeness

https://github.com/dotnet/csharplang/issues/6476

While we're not a huge fan of this proposal as a general principle, we think it has merits. unsafe in C# is generally concerned with allowing users to express patterns that are memory unsafe, and this proposal doesn't change that principle; it simply extends that memory unsafety to a new area. Importantly, users will have a way to express these semantics, regardless of whether the language changes here, as Unsafe will still exist. This proposal ensures that for such code, users will at least be warned, rather than silently getting no feedback whatsoever.

Conclusion

Approved for C# 11.