# C# Language Design Meeting for March 21st, 2022

## Agenda

1. [file private visibility](#file-private-visibility)
2. [Open question in semi-auto properties](#open-question-in-semi-auto-properties)
3. [Open question in required members](#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:

```cs
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.
