Skip to content

Conversation

MadsTorgersen
Copy link
Contributor

Prevent classes that derive from closed classes from having "free" type parameters, since that would prevent an exhaustive switch.

@MadsTorgersen MadsTorgersen requested a review from a team as a code owner July 29, 2025 19:46
@@ -55,6 +55,19 @@ public class C1 : CC { ... } // Error, 'CC' is closed and in a different ass
public class C2 : CO { ... } // Ok, 'CO' is not closed
```

### Type parameter restriction

If a generic class directly derives from a closed class, then all if its type parameters must be used in the base class specification:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
If a generic class directly derives from a closed class, then all if its type parameters must be used in the base class specification:
If a generic class directly derives from a closed class, then all of its type parameters must be used in the base class specification:

Copy link
Contributor

@jnm2 jnm2 Jul 30, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we define "used in" precisely? What about:

closed class C<T1, T2>;
class D1<T1, T2> : C<int, Tuple<T1, T2>>;

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we define "used in" precisely? What about:

closed class C<T1, T2>;
class D1<T1, T2> : C<int, Tuple<T1, T2>>;

This still works. The type parameters in the two types do not have to be the same, the type parameters from the sub-type just need to be used in the reference to the base type.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Got it; when switching over a given C<...> in that case, T1 and T2 are held constant across the switch and exhaustivity doesn't have to worry about a varying type parameter in the derived class.

@MadsTorgersen MadsTorgersen merged commit bcf9718 into main Aug 18, 2025
1 check passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants