Added LDM notes for September 21st, 2022.

meetings/2022/LDM-2022-09-21.md

@@ -0,0 +1,64 @@
+# 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.

meetings/2022/README.md

@@ -39,15 +39,22 @@ All schedule items must have a public issue or checked in proposal that can be l
 
 - Triage [working set](https://github.com/dotnet/csharplang/issues?q=is%3Aopen+is%3Aissue+milestone%3A%22Working+Set%22) and determine working groups (Mads) 
 
-## Wed Sep 21, 2022
-
-- Triage [new championed features](https://github.com/dotnet/csharplang/issues?q=is%3Aopen+is%3Aissue+label%3A%22Proposal+champion%22+no%3Amilestone) (Mads)
-- Change ref safety errors to warnings inside unsafe (Jared): https://github.com/dotnet/csharplang/issues/6476
-
 # C# Language Design Notes for 2022
 
 Overview of meetings and agendas for 2022
 
+## Wed Sep 21, 2022
+
+[C# Language Design Meeting for September 21st, 2022](https://github.com/dotnet/csharplang/blob/main/meetings/2022/LDM-2022-09-21.md)
+
+- [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)
+
 ## Wed Aug 31, 2022
 
 [C# Language Design Meeting for August 31st, 2022](https://github.com/dotnet/csharplang/blob/main/meetings/2022/LDM-2022-08-31.md)