Added LDM notes for April 11th, 2022.

meetings/2022/LDM-2022-04-11.md

@@ -0,0 +1,47 @@
+# C# Language Design Meeting for April 11th, 2022
+
+## Agenda
+
+1. [Relax restrictions on braces on raw interpolated strings](#relax-restrictions-on-braces-on-raw-interpolated-strings)
+2. [Self-type stopgap attribute](#self-type-stopgap-attribute)
+
+## Quote of the Day
+
+- "Maybe we should introduce the £ symbol for interpolated strings"
+
+## Discussion
+
+### Relax restrictions on braces on raw interpolated strings
+
+https://github.com/dotnet/csharplang/issues/5960
+
+After some initial usage of raw string literals, we wanted to revisit the reasoning behind limiting the number of `{`'s just before an interpolation
+hole, as it came up as confusing to explain to several users. The idea is that, before an interpolation hole, users would be able to specify as many
+`{` characters as they wanted, and the compiler would only treat the inner `{`'s that make up an interpolation hole as the delimiters. This would allow
+`$""" {{0}} """` to be a string with the content ` {0} `. There are, however, some potential issues with this:
+
+1. In 99% of cases a `{` in an interpolated raw string literal with a single `$` is not permitted, as such a character denotes the start of an interpolation
+hole. Relaxing this restriction would be odd, as `{ {0}` would be disallowed, but `{{0}` would be allowed.
+2. The rules as is are consistent with the rules for the quotes, and changing the rules would require that users understand multiple sets of rules.
+3. `$"{{expr}}"` has meaning today, as a string with the content of `{expr}`. If we permitted `$"""{{expr}}"""` to compile, it might end up confusing
+users who expect it to have a similar meaning to existing interpolated strings.
+
+#### Conclusion
+
+We will keep the restriction as is.
+
+### Self-type stopgap attribute
+
+https://github.com/dotnet/csharplang/issues/6000
+
+As an attempt to prevent simple user errors with our new numeric interfaces, and preserve the potential to use self types in those interfaces in a future
+where we add support for them, we considered an attribute that could be applied to type parameters to enforce that the type parameter can only be substituted
+with the containing type, or a type parameter that is also attributed with the same attribute. We quickly started delving into the nitty gritty of the
+implementation: should we allow it on abstract classes, for example, or be more opinionated with where the parameter so attributed must occur? However, we
+came to the conclusion as we were doing this that we were creating `GenericMathSelfTypeAttribute`, not a generalized `SelfTypeAttribute`. We don't have the
+broader understanding of the usage of self-type type parameters of the entire ecosystem to attempt to rush in a generalized protection feature here, and
+think the space is more appropriate for an analyzer in the BCL to enforce the rules that matter for the interfaces in question.
+
+#### Conclusion
+
+Rejected. We will look at a BCL analyzer to enforce the rules they want to enforce for these interfaces.

meetings/2022/README.md

@@ -28,15 +28,17 @@ All schedule items must have a public issue or checked in proposal that can be l
 - Feedback on `!!` continued: https://github.com/dotnet/csharplang/blob/main/proposals/param-nullchecking.md
 - File-scoped declarations revisited (Mads, Rikki, Jared, Stephen): 
 
-## Apr 11, 2022
-
-- Relax raw interpolated string limitations on number of braces (cyrusn): https://github.com/dotnet/csharplang/issues/5960
-- Self type mitigation (Mads): https://github.com/dotnet/csharplang/issues/6000
-
 # C# Language Design Notes for 2022
 
 Overview of meetings and agendas for 2022
 
+## Apr 11, 2022
+
+[C# Language Design Meeting for April 11th, 2022](https://github.com/dotnet/csharplang/blob/main/meetings/2022/LDM-2022-04-11.md)
+
+1. Relax restrictions on braces on raw interpolated strings
+2. Self-type stopgap attribute
+
 ## Apr 6, 2022
 
 [C# Language Design Meeting for April 6th, 2022](https://github.com/dotnet/csharplang/blob/main/meetings/2022/LDM-2022-04-06.md)