C# Language Design Meeting for February 16th, 2022

Agenda

1. Open questions in field
2. Triage
   1. User-defined positional patterns
   2. Delegate type arguments improvements
   3. Practical existential types for interfaces
   4. 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, 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.