# C# Language Design Meeting for February 16th, 2022

## Agenda

1. [Open questions in `field`](#open-questions-in-field)
2. [Triage](#triage)
    1. [User-defined positional patterns](#user-defined-positional-patterns)
    2. [Delegate type arguments improvements](#delegate-type-arguments-improvements)
    3. [Practical existential types for interfaces](#practical-existential-types-for-interfaces)
    4. [Static abstract interfaces and static classes](#static-abstract-interfaces-and-static-classes)

## Quote of the Day

- "It's not as if we don't have guns lying around that you can point at your foot in the rest of the language"

## Discussion

### Open questions in `field`

https://github.com/dotnet/csharplang/issues/5703  
https://github.com/dotnet/csharplang/issues/140

Our open question today is whether `field` can be shadowed in a nested scope in a semi-auto property. For prior art, we looked at two scenarios:

1. In C# today, fields can be shadowed by parameters or locals. This is done intentionally, as it is a common pattern to have a local or parameter with the same
name, and then assign to the type's field by using `this.` as a prefix. We don't have that same intentionality of purpose here: `field` does represent an anonymous
field in the type, but that field isn't actually named `field`, and there's very little logical reason to name a local `field` to intentionally shadow the implicit
backing field keyword.
2. `value` is an invalid local name in property setters, as there is an implicit parameter named `value` and parameters cannot be shadowed by locals. However, the
reasoning doesn't appear to hold water for `field`, as `field` is not parameter.

Ultimately, we think that since `field` represents a field in the type, even if anonymously, the shadowing rules of regular fields should apply. This means that the
`field` keyword can be shadowed by parameters or locals in a nested scope.

#### Conclusion

`field` can be shadowed by parameters or locals in a nested scope.

### Triage

#### User-defined positional patterns

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

User-defined patterns, also known as active patterns in F#, are extremely powerful, but when designing them we need to be sure we're not painting ourselves into a
design corner for other future pattern enhancements. There are also some interesting questions we will have to answer around exhaustiveness. Regardless of these
questions, we see active patterns as one of the last pattern-related things that need to be added to the pattern feature to make it generally "complete", and are
excited to look at them after we land the current pattern work.

##### Conclusion

Into the backlog, for after we finish the current pattern features.

#### Delegate type arguments improvements

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

We previously looked at this in LDM [here](https://github.com/dotnet/csharplang/blob/main/meetings/2021/LDM-2021-10-25.md#delegate-type-argument-improvements), but
didn't triage it at this time. Our feelings haven't changed, and we want more exploration of the generalized version before more active work can continue.

##### Conclusion

Into the backlog.

#### Practical existential types for interfaces

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

There is still some discomfort on the LDM around munging of generic parameter lists, but we like having a real translation proposal for this. We wonder if there is
some way that, with the restrictions imposed on existential types in this proposal, we could have the runtime do the translation without previously-expressed concerns
about combinatoric generic explosion, since all usages of these interfaces must already be generic. We think this will be a good thing to explore post roles, as we're
actively thinking about them now and don't want to have too many huge type-system changes in flight at the same time.

##### Conclusion

Into the backlog.

#### Static abstract interfaces and static classes

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

This would be a nice hole to fill, as long as it comes with either an anti-constraint for allowing static classes as type parameters, or simply removing the restriction
entirely.

##### Conclusion

Into the working set.
