# C# Language Design Meeting for September 21st, 2022

## Agenda

- [Unchampioned issue triage](#unchampioned-issue-triage)
    - [Track subtype exhaustiveness for classes with only private constructors](#track-subtype-exhaustiveness-for-classes-with-only-private-constructors)
    - [ReadOnlySpan initialization from static data](#readonlyspan-initialization-from-static-data)
    - [Embedded Language Indicators for raw string literals](#embedded-language-indicators-for-raw-string-literals)
    - [Implicit Parameters](#implicit-parameters)
- [Unsafer Unsafeness](#unsafer-unsafeness)
    - [Conclusion](#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.
