C# Language Design Meeting for March 28th, 2022

Agenda

1. Variable declarations under disjunctive patterns
2. Type hole in static abstracts
3. Self types

Quote of the Day

• "That feels like a baby we might throw out with the bathwater"

Discussion

Variable declarations under disjunctive patterns

https://github.com/dotnet/csharplang/issues/4018
https://github.com/dotnet/csharplang/blob/b6f901132d4ee299157bc9b1745eb578f30d29ef/proposals/pattern-variables.md

Last time we discussed this issue, we felt that there were potential dragons in two directions:

1. Should we re<i>declare</i> existing variables, or have a syntax for assigning into them?
2. Should we allow assignment/declaration into all variables in scope?

This update to the proposal attempts to address the latter concern: the former discussion has not yet been had. The updated version of the proposal suggests using definite assignment to determine when a variable can be assigned into: if the variable has a flow state of "not definitely assigned", it can be redeclared in a pattern, and defines definite assignment rules for inside patterns to allow the rules to generalize within patterns and without.

There are still some concerns that this is too wide of a scope. Our motivations in this proposal are around allowing sharing blocks of code: allowing case clauses to enter a specific body in a switch statement with the appropriate information extracted, for example, or allowing multiple conditions to be put on either side of an || as part of the condition of an if statement. The goal isn't to allow general redeclaration: it's to allow sharing of code. Redeclaring or reusing between unrelated conditions concerns us more: should consecutive if statements be able to reuse that name and stomp on that location? Because it refers to a location, a previous if body could have passed a ref to another area, which could then observe the write to the local.

Within a single related construct, however, we think using definite assignment as the mechanism for enforcement is a good solution. While it's not a perfect "definitely not assigned", it limits the redeclaration points and it's much harder to observe state being assigned (not impossible, but much harder, particularly unintentionally). We still need to consider ways to address the first concern, but that exploration will need to be the next meeting.

Conclusion

We would like to scope down the allowed location for redeclaration/assignment to:

1. Within case labels for the same switch section.
2. Within a single expression.
3. Within related statements: an if/else if, for example, but not in two unconnected if statements.

Type hole in static abstracts

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

A variation of this issue is what stopped the original exploration of static abstracts from proceeding a decade ago: we addressed the wider hole with the existing restriction, but the hole is still possible to exploit. We therefore are ok with this further restriction, but think that when we add support for static virtual members, we should work with the runtime team to make sure that, if all static virtual members of an interface have a body, it should be usable as a type argument. This would avoid the breaking change from adding a static virtual DIM to an interface, which despite not requiring consumers to update implementing code, would potentially break usage as a type argument.

Conclusion

Restriction is accepted.

Self types

https://github.com/dotnet/csharplang/issues/5413#issuecomment-1079584415

After considering Mads' feedback on self types, we find ourselves agreeing with it. It would be very concerning that we would introduce a version of self types now, marginally improving the usability of generic math but potentially breaking our ability to evolve the type system further.

Conclusion

Self types in this form are rejected.