[Version 9.0] Feature support for unconstrained type parameter annotations - #1470
Draft
BillWagner wants to merge 7 commits into
Draft
[Version 9.0] Feature support for unconstrained type parameter annotations#1470BillWagner wants to merge 7 commits into
BillWagner wants to merge 7 commits into
Conversation
RexJaeschke
added
type: feature
Member
Author
|
I can't add a suggestion here yet, but this text needs to be removed from types.md:
It's being proposed in #1575. It's no longer correct for v9. |
BillWagner
added
the
meeting: discuss
BillWagner
removed
the
meeting: discuss
BillWagner
force-pushed
the
v9-unconstrainted-type-parameter
branch
from
April 10, 2026 21:56
1fbcb02 to
30b3684
Compare
BillWagner
added a commit
that referenced
this pull request
Apr 10, 2026
…- 2 new commits Delta: 2 commits (b37dedc Update classes.md, 30b3684 Review and update text) Base: d68b04d (draft-v9 merge commit) / Original: 4e5e0a6 (alpha-v9) Conflicts resolved: 2 in classes.md - Conflict 1: Kept 'do not' wording (contractions already expanded on alpha-v9) - Conflict 2: Merged covariant return type bullets (PR #1462) with new default constraint support (PR #1470)
BillWagner
force-pushed
the
v9-unconstrainted-type-parameter
branch
from
May 12, 2026 22:01
30b3684 to
995251f
Compare
BillWagner
force-pushed
the
v9-unconstrainted-type-parameter
branch
from
June 24, 2026 17:36
995251f to
aa52bc5
Compare
Member
Author
|
An earlier version of this feature is already present on |
BillWagner
added
the
meeting: discuss
Member
Author
|
@jskeet If there is time after other agenda items, this is close and could use comments from other committee members. |
Contributor
|
Yup, I strongly suspect we'll have plenty of time. |
Contributor
|
Aim is get approval (or lack thereof) of general shape and first draft comments, so @BillWagner can make changes ready for a second round of review before the next meeting. Added all team members to review. |
BillWagner
added a commit
that referenced
this pull request
Jul 22, 2026
Found based on #1470 and #1471 In our 7/22 meeting, we merged updated features for both C# 8 and C# 9. The tools did the correct work, but made all commits on one branch. So, both of these PRs picked up changes from the v8 and v9 PRs. This change instructs the workflow to create the pull request branch name based on the base branch version it started with. Doing that means it will not accidentically cross versions when the automation runs.
BillWagner
added a commit
that referenced
this pull request
Jul 23, 2026
Found based on #1470 and #1471 In our 7/22 meeting, we merged updated features for both C# 8 and C# 9. The tools did the correct work, but made all commits on one branch. So, both of these PRs picked up changes from the v8 and v9 PRs. This change instructs the workflow to create the pull request branch name based on the base branch version it started with. Doing that means it will not accidentically cross versions when the automation runs.
- Act on existing TODO markers
Remove the restriction in classes.md: "The nullable type annotation, ?, can only be used on a type parameter that has the value type constraint, the reference type constraint without the nullable_type_annotation, or a class type constraint without the nullable_type_annotation."
Replace it with the C# 9 rule from the feature spec: unless a type parameter is explicitly constrained to value types, ? annotations can only be applied within a #nullable enable context.
Uncomment and integrate classes.md: "For a type parameter T when the type argument is a nullable reference type C?, instances of T? are interpreted as C?, not C??." (currently inside a <!-- Add in C# 9 --> comment).
— Override/explicit implementation constraint list
In classes.md, the text says: "Such declarations may only have type_parameter_constraints_clauses containing the primary_constraints class and struct…"
Add default to this list (e.g., "…the primary_constraints class, struct, and default…") and reference the new §15.6.5 and §19.6.2 meaning.
— Override method T? interpretation rules
In classes.md, the current rule only covers class and struct constraints and describes how T? is interpreted in overriding signatures. Update to add the default case:
If a default constraint is added for type parameter T, then T? represents the annotated type — a nullable reference type when T is a reference type, or just T when T is a value type (matching the feature spec behavior; no U??).
Consider adding an example analogous to the feature spec's A2/B2 example showing where T : default on an override of an unconstrained method.
— Explicit interface implementation T? interpretation rules
In interfaces.md, same situation as §15.6.5: update to add the default constraint case and its T? interpretation.
The text ("Without the type parameter constraint where T : class, the base method with the reference-typed type parameter cannot be overridden.") should be updated or supplemented with an example using where T : default for an unconstrained interface method.
Found a few nits, and a couple places where the old restriction that is removed by this feature were still referenced.
BillWagner
force-pushed
the
v9-unconstrainted-type-parameter
branch
from
July 24, 2026 19:50
bbc5ca5 to
62301d7
Compare
jskeet
reviewed
Jul 29, 2026
jskeet
left a comment
jskeet
left a comment
Contributor
There was a problem hiding this comment.
Various comments around clarity, but I think the overall shape/approach is fine.
| A primary constraint can be a class type, the ***reference type constraint*** `class`, the ***value type constraint*** `struct`, the ***not null constraint*** `notnull` or the ***unmanaged type constraint*** `unmanaged`. The class type and the reference type constraint can include the *nullable_type_annotation*. | ||
| A primary constraint can be a class type, the ***reference type constraint*** `class`, the ***value type constraint*** `struct`, the ***not null constraint*** `notnull`, the ***unmanaged type constraint*** `unmanaged`, or `default`. The class type and the reference type constraint can include the *nullable_type_annotation*. | ||
|
|
||
| It is a compile-time error to use a `default` constraint other than on a method override or explicit implementation. It is a compile-time error to use a `default` constraint when the corresponding type parameter in the overridden or interface method is constrained to a reference type or value type. |
Contributor
There was a problem hiding this comment.
Perhaps "explicit implementation" => "explicit interface implementation"? Not really required, just a thought.
| A primary constraint can be a class type, the ***reference type constraint*** `class`, the ***value type constraint*** `struct`, the ***not null constraint*** `notnull` or the ***unmanaged type constraint*** `unmanaged`. The class type and the reference type constraint can include the *nullable_type_annotation*. | ||
| A primary constraint can be a class type, the ***reference type constraint*** `class`, the ***value type constraint*** `struct`, the ***not null constraint*** `notnull`, the ***unmanaged type constraint*** `unmanaged`, or `default`. The class type and the reference type constraint can include the *nullable_type_annotation*. | ||
|
|
||
| It is a compile-time error to use a `default` constraint other than on a method override or explicit implementation. It is a compile-time error to use a `default` constraint when the corresponding type parameter in the overridden or interface method is constrained to a reference type or value type. |
Contributor
There was a problem hiding this comment.
Just to check, "is constrained to a reference type or value type" includes a class type constraint, right? (So I can't write where T : Stream, default.
It's all slightly confusing that there's the reference type constraint which is spelled class which is different from a class type constraint which itself constrains it to be a reference type... not that we can do anything about that now.
|
|
||
| <!-- Remove in C# 9, when `?` is allowed on any type parameter. --> | ||
| The nullable type annotation, `?`, can only be used on a type parameter that has the value type constraint, the reference type constraint without the *nullable_type_annotation*, or a class type constraint without the *nullable_type_annotation*. | ||
| Except when a type parameter is explicitly constrained to value types, the nullable type annotation `?` can only be applied to a type parameter when the nullable annotations flag is enabled ([§6.5.9](lexical-structure.md#659-nullable-directive)). |
Contributor
There was a problem hiding this comment.
Constrained to non-nullable value types?
Contributor
There was a problem hiding this comment.
I think this comment may still be relevant.
| > } | ||
| > ``` | ||
| > | ||
| > The `default` constraint on `B2.F2` is required to override the unconstrained `A2.F2` with a `T?` parameter. Without it, `T?` in the second override would be interpreted as a nullable value type, so the declaration would not override the unconstrained `A2.F2`. *end example* |
Contributor
There was a problem hiding this comment.
This is a really good example - but wow this is a confusing bit of the language. (At least for me...)
I'm hoping this is a corner case that needs to be specified because that's what we do, but which most people never run into.
Contributor
There was a problem hiding this comment.
(Leaving this comment unresolved in case we want to discuss it in meetings.)
- Fix malformed HTML comment (missing '<') in classes.md MD028 disable - Replace 'explicit implementation'/'explicit interface method implementation' with 'explicit interface member implementation' in reviewed constraints prose - Add Note clarifying that a class type constraint (e.g. 'where T : Stream') constrains the type parameter to a reference type - Tighten 'value types' to 'non-nullable value types' in the parallel class/struct constraint description in classes.md and interfaces.md - Replace passive 'applies to'/'are applied to'/'is applied to' with active 'may be used for'/'may be placed on' in reviewed constraint clauses - Replace 'instance of a type parameter' with 'occurrence of a type parameter' in types.md Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Rewrite the dense 'default' constraint T? bullet in classes.md and interfaces.md. The three cases (reference type, already-annotated reference type, value type) are now independent sub-bullets so each can be read on its own. Normative meaning is unchanged. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Member
Author
|
The two most recent commits address all Jon's comments. |
Contributor
|
Will review on Wednesday (driving tomorrow) |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR replaces #1326