C# Language Design Meeting for March 30th, 2022

Agenda

1. Definite assignment in struct constructors calling : this()
2. 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.