csharplang/meetings/2022/LDM-2022-03-21.md

C# Language Design Meeting for March 21st, 2022

Agenda

1. file private visibility
2. Open question in semi-auto properties
3. Open question in required members

Quote of the Day

• "If we pick one syntax, we can have a quick meeting" Collective laughter

Discussion

file private visibility

https://github.com/dotnet/csharplang/issues/5529

Our discussions today were on both syntax, and the semantics of what differing syntaxes mean. We see problems with both presented options of file private and private:

• For file private, what does that mean when applied to member of a type? Is that member private to the member and also private to the file? What does the private part of file private mean when applied to a top-level type?
• For private, this is inconsistent with how private can already be applied to types in nested contexts: what if we wanted to enable nested file private types in the future?

To address these issues, we thought about a variation on file private: file <accessibility>. This would add file as a modifier on all current accessibilities, restricting their scope to be the current file. So file public would allow access to everything in the current file, while file private would only allow access to things in the containing member (and would not be allowed to apply to a top-level type, as just private isn't allowed to do this). However, there are a lot of interesting side-effects from things like public vs private accessibility: it has impacts on reflection, dynamic, serialization, and more. We're somewhat concerned about these potential effects, and want to be very careful about allowing these things for types and members that ostensibly only accessible inside a single file. We therefore want to take a look at what the minimal solution to address the motivation without blocking off future development work would look like: perhaps just file, which would inherit the default accessibility of the location, with no other accessibility specifiers allowed, but this will be looked at in a smaller group and revisited soon.

Conclusion

No decisions today. We'll rethink with a file keyword approach see what the downsides are.

Open question in semi-auto properties

https://github.com/dotnet/csharplang/issues/5923

Our model is that field reflects an actual field of the type, and rules should flow out from that. Since in this case a field is a static field, and static lambdas can access static fields, a static lambda can access field, even if it doing so is what causes the field to be brought into existence.

Conclusion

Allowed.

Open question in required members

https://github.com/dotnet/csharplang/issues/3630

Our final question today is on whether we should issue warnings for this scenario, where a required member is being initialized to a value:

class C
{
    public required int Field = 1;
    public required int Prop { get; set; } = 1;
}

After some consideration, we think that there could be potential scenarios if a type exposed multiple constructors, and several of them were marked SetsRequiredMembers. These constructors could be sharing this initializer, but any remaining constructors will require that consumers set a value. An analyzer seems appropriate if a user wants to forbid redundant assignments here.

Conclusion

No warning.