diff --git a/meetings/2022/LDM-2022-03-30.md b/meetings/2022/LDM-2022-03-30.md new file mode 100644 index 00000000..28f091db --- /dev/null +++ b/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. diff --git a/meetings/2022/README.md b/meetings/2022/README.md index a169121d..7946b6eb 100644 --- a/meetings/2022/README.md +++ b/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)