Added LDM notes for March 30th, 2022.

This commit is contained in:
Fredric Silberberg 2022-03-30 17:52:14 -07:00
Родитель 68bfceaaa0
Коммит 29ebb4389d
Не найден ключ, соответствующий данной подписи
Идентификатор ключа GPG: EEEEFE2293400B4A
2 изменённых файлов: 72 добавлений и 6 удалений

Просмотреть файл

@ -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.

Просмотреть файл

@ -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)