Added LDM notes for March 30th, 2022.

meetings/2022/LDM-2022-03-30.md

@@ -0,0 +1,64 @@
+# C# Language Design Meeting for March 30th, 2022
+
+## Agenda
+
+1. [Definite assignment in struct constructors calling `: this()`](#definite-assignment-in-struct-constructors-calling--this)
+2. [`file private` accessibility](#file-private-accessibility)
+
+## Quote of the Day
+
+- "Maybe we should renumber that list so we're not confused? I know we're all programmers, but 0-based is confusing here." "We're all programmers, but VB programmers at heart."
+
+## Discussion
+
+### Definite assignment in struct constructors calling `: this()`
+
+https://github.com/dotnet/roslyn/issues/58790  
+https://github.com/dotnet/csharplang/issues/5552
+
+For solving this issue, we generated the following ideas:
+
+1. No change to the behavior, and document it. We don't really think this is tenable, but it is technically an option.
+2. Report an error calling `: this()` when field initializers are present and `this()` is a default parameterless constructor.
+3. No error; zero fields after running initializers (silent breaking change to existing code).
+4. No error, zero fields before running initializers.
+5. Option #4 for now (C# 10), then #2 later.
+6. Option #4 for now (C# 10), add a warning wave later on uses of `: this()` or `new S()` when there is no user-defined parameterless constructor.
+
+Several LDM members immediately felt that 4 was the correct option, and did what they were expecting the code to do. However, it does carry with it the potential for
+confusion around what calling the parameterless constructor does: for a struct with no parameterless constructor with field initializers, the behavior of `: this()`
+and of `new S()` will appear to differ. We may specify that field initializers run in a different order, but the perception will likely be different. Option 2 would
+be a consistent way of correcting this perception issue: either make the behavior between all references to a parameterless constructor identical, or forbid calling a
+parameterless constructor where behavior would be confusing. However, while this option is most in line with C# of the past, we are already planning on making big
+changes to struct initialization in C# 11, and this behavior would have the unfortunate behavior of punishing any user that adds a field initializer to existing structs
+that already use `: this()` in places.
+
+We're also concerned about a warning wave here, as there are plenty of uses of `: this()` as a struct initializer that are perfectly fine today that would become
+warnings if we took a hard line stance here. It might be better to approach such a ruling a code style thing: the IDE can gray out the `: this()` initializer in C# 11,
+and fixers can remove dead code as they do today.
+
+#### Conclusion
+
+We will adopt option 4 for C# 10, and look into code style analyzers and IDE experiences to remove potentially confusing and redundant use of `: this()` in C# 11.
+
+### `file private` accessibility
+
+https://github.com/dotnet/csharplang/issues/5969  
+https://github.com/dotnet/csharplang/issues/5529
+
+We looked at another turn of the crank in the proposal around `file private`. The proposal today goes for a very integrated approach, adding a new accessibility modifier
+and rationalizing its existence with other accessibilities, paring the accessibilities that can be combined with `file` down to a small set. Through discussion, we
+arrived at 3 proposal options:
+
+1. #5969 as is.
+2. `file` or `fileonly` as a new accessibility. It cannot be combined with other accessibilities, and means only "can be accessed in this file".
+3. `file` is allowed to be combined with any existing accessibility. Everything works exactly as it does today, but when `file` is applied, the name is not in scope
+outside the current file.
+
+We think that option 1 has the potential to be complicated. Both 2 and 3 are relatively simple to explain, with 2 being the simpler of them. Option 1 limits and changes
+existing rules when `file` is applied, which starts to need a decoder ring to understand.
+
+#### Conclusion
+
+We're equally split between option 2 and 3 at this point. We need to explore these a bit more with a smaller group, clarify the motivating scenarios for the feature, and
+come back soon for another session.

meetings/2022/README.md

@@ -4,6 +4,7 @@ All schedule items must have a public issue or checked in proposal that can be l
 
 ## Schedule ASAP
 
+- Open questions with static virtual members (Aleksey): https://github.com/dotnet/csharplang/blob/main/proposals/static-abstracts-in-interfaces.md
 - Relax requirement that in a RAW interpolated string that you cannot have more than 2n-1 braces in a row (where N is the number of $ signs).  (cyrusn).  https://github.com/dotnet/csharplang/issues/5960
 
 
@@ -30,16 +31,17 @@ All schedule items must have a public issue or checked in proposal that can be l
 
 - Feedback on `!!`: https://github.com/dotnet/csharplang/blob/main/proposals/param-nullchecking.md
 
-## Mar 30, 2022
-
-- Specify behavior of default `this()` struct constructor initializer with field initializers (Chuck, Rikki): https://github.com/dotnet/roslyn/issues/58790
-- File-scoped declarations (Rikki): https://github.com/dotnet/csharplang/issues/5969
-- Open questions with static virtual members (Aleksey): https://github.com/dotnet/csharplang/blob/main/proposals/static-abstracts-in-interfaces.md
-
 # C# Language Design Notes for 2022
 
 Overview of meetings and agendas for 2022
 
+## Mar 30, 2022
+
+[C# Language Design Meeting for March 30th, 2022](https://github.com/dotnet/csharplang/blob/main/meetings/2022/LDM-2022-03-30.md)
+
+1. Definite assignment in struct constructors calling `: this()`
+2. `file private` accessibility
+
 ## Mar 28, 2022
 
 [C# Language Design Meeting for March 28th, 2022](https://github.com/dotnet/csharplang/blob/main/meetings/2022/LDM-2022-03-28.md)