# C# Language Design Meeting for March 28th, 2022

## Agenda

1. [Variable declarations under disjunctive patterns](#variable-declarations-under-disjunctive-patterns)
2. [Type hole in static abstracts](#type-hole-in-static-abstracts)
3. [Self types](#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](../../proposals/static-abstracts-in-interfaces.md#interface-constraints-with-static-abstract-members), 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.
