[Version 9.0] Feature support for unconstrained type parameter annotations by BillWagner · Pull Request #1470 · dotnet/csharpstandard

BillWagner · 2025-11-11T22:04:08Z

This PR replaces #1326

BillWagner · 2026-02-17T21:51:56Z

I can't add a suggestion here yet, but this text needs to be removed from types.md:

Nullable annotations (?) aren't allowed on an instance of a type parameter unless that type parameter is constrained to be either a reference type or a value type.

It's being proposed in #1575. It's no longer correct for v9.

…- 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 · 2026-06-24T18:33:24Z

An earlier version of this feature is already present on alpha-v9 from a prior meeting. Edits made to this PR since then are not yet on alpha-v9; they will land at the next propagation. If you need them on alpha-v9 sooner, please open a separate PR targeting alpha-v9.
Thanks!

BillWagner · 2026-07-16T20:33:05Z

@jskeet If there is time after other agenda items, this is close and could use comments from other committee members.

jskeet · 2026-07-17T06:45:46Z

Yup, I strongly suspect we'll have plenty of time.

jskeet · 2026-07-22T19:59:33Z

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.

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  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.

jskeet

Various comments around clarity, but I think the overall shape/approach is fine.

jskeet · 2026-07-29T08:26:10Z

-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.


Perhaps "explicit implementation" => "explicit interface implementation"? Not really required, just a thought.

jskeet · 2026-07-29T08:27:50Z

-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.


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.

jskeet · 2026-07-29T08:28:35Z


-<!-- 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)).


Constrained to non-nullable value types?

jskeet · 2026-07-29T08:32:22Z


 Because `unmanaged` is not a keyword, in *primary_constraint* the unmanaged constraint is always syntactically ambiguous with *class_type*. For compatibility reasons, if a name lookup ([§12.8.4](expressions.md#1284-simple-names)) of the name `unmanaged` succeeds it is treated as a `class_type`. Otherwise it is treated as the unmanaged constraint.

+The `default` constraint applies to a type parameter whose inherited constraints do not establish it as a reference type or a value type; its effect on `T?` in override methods and explicit interface method implementations is specified in [§15.6.5](classes.md#1565-override-methods) and [§19.6.2](interfaces.md#1962-explicit-interface-member-implementations).


"applies to a type parameter" feels a bit odd here. Is it actually "can be applied to a type parameter" or have I missed something?

And possibly remove "method" from "explicit interface method implementations"?

jskeet · 2026-07-29T08:34:01Z

- A *type_parameter_constraints_clause* may only consist of the `class` or `struct` *primary_constraint*s applied to *type_parameter*s which are known according to the inherited constraints to be either reference or value types respectively. Any type of the form `T?` in the overriding method’s signature, where `T` is a type parameter, is interpreted as follows:
-  - If a `class` constraint is added for type parameter `T` then `T?` is a nullable reference type; otherwise
-  - If either there is no added constraint, or a `struct` constraint is added, for the type parameter `T` then `T?` is a nullable value type.
+- A *type_parameter_constraints_clause* may only consist of the `class`, `struct`, or `default` *primary_constraint*s. The `class` and `struct` constraints are applied to *type_parameter*s which are known according to the inherited constraints to be either reference or value types respectively. The `default` constraint is applied to *type_parameter*s that are not constrained to either reference or value types. Any type of the form `T?` in the overriding method’s signature, where `T` is a type parameter, is interpreted as follows:


Again the "are applied" and "is applied" feel slightly confusing to me.

jskeet · 2026-07-29T08:37:05Z

+- A *type_parameter_constraints_clause* may only consist of the `class`, `struct`, or `default` *primary_constraint*s. The `class` and `struct` constraints are applied to *type_parameter*s which are known according to the inherited constraints to be either reference or value types respectively. The `default` constraint is applied to *type_parameter*s that are not constrained to either reference or value types. Any type of the form `T?` in the overriding method’s signature, where `T` is a type parameter, is interpreted as follows:
+  - If a `class` constraint is added for type parameter `T` then `T?` is a nullable reference type.
+  - If either a `struct` constraint is added, or no constraint is added and the inherited constraint is a value type constraint, for the type parameter `T` then `T?` is a nullable value type.
+  - If a `default` constraint is added for type parameter `T` then `T?` represents a nullable instance of the corresponding reference type when `T` is a reference type, and an instance of `T` when `T` is a value type. If `T` is substituted with an annotated type `U?`, then `T?` represents `U?`, not `U??`.


I don't understand this bullet at the moment.

jskeet · 2026-07-29T08:39:11Z

+> }
+> ```
+>
+> 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*


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.

jskeet · 2026-07-29T08:39:43Z

 An explicit interface method implementation inherits any type parameter constraints from the interface.

-A *type_parameter_constraints_clause* on an explicit interface method implementation may only consist of the `class` or `struct` *primary_constraint*s applied to *type_parameter*s which are known according to the inherited constraints to be either reference or value types respectively. Any type of the form `T?` in the signature of the explicit interface method implementation, where `T` is a type parameter, is interpreted as follows:
+A *type_parameter_constraints_clause* on an explicit interface method implementation may only consist of the `class`, `struct`, or `default` *primary_constraint*s. The `class` and `struct` constraints are applied to *type_parameter*s which are known according to the inherited constraints to be either reference or value types respectively. The `default` constraint is applied to *type_parameter*s that are not constrained to either reference or value types. Any type of the form `T?` in the signature of the explicit interface method implementation, where `T` is a type parameter, is interpreted as follows:


Again, "is applied" feels confusing to me.

jskeet · 2026-07-29T08:41:13Z

- If either there is no added constraint, or a `struct` constraint is added, for the type parameter `T` then `T?` is a nullable value type.
+- If a `class` constraint is added for type parameter `T` then `T?` is a nullable reference type.
+- If either a `struct` constraint is added, or no constraint is added and the inherited constraint is a value type constraint, for the type parameter `T` then `T?` is a nullable value type.
+- If a `default` constraint is added for type parameter `T` then `T?` represents a nullable instance of the corresponding reference type when `T` is a reference type, and an instance of `T` when `T` is a value type. If `T` is substituted with an annotated type `U?`, then `T?` represents `U?`, not `U??`.


As per classes.md line 2770, I don't understand this bullet point.

jskeet · 2026-07-29T08:42:18Z

 > - A type parameter cannot be used in a member access ([§12.8.7](expressions.md#1287-member-access)) or type name ([§7.8](basic-concepts.md#78-namespace-and-type-names)) to identify a static member or a nested type.
 > - A type parameter can only be used as an *unmanaged_type* ([§8.8](types.md#88-unmanaged-types)) if the type parameter is constrained by the unmanaged constraint ([§15.2.5](classes.md#1525-type-parameter-constraints)).
-> - Nullable annotations (`?`) aren’t allowed on an instance of a type parameter unless that type parameter is constrained to be either a reference type or a value type ([§15.2.5](classes.md#1525-type-parameter-constraints)).  
+> - Except when a type parameter is explicitly constrained to value types, the nullable type annotation (`?`) can only be applied to an instance of a type parameter when the nullable annotations flag is enabled ([§6.5.9](lexical-structure.md#659-nullable-directive), [§15.2.5](classes.md#1525-type-parameter-constraints)).  


I think I understand what "instance" means here, but that an alternative would be better. (It means "a situation where it occurs in the source code" right?) I don't have a better word right now, but we should brainstorm it.

BillWagner mentioned this pull request Nov 11, 2025

Add support for unconstrained type parameter annotations #1326

Closed

RexJaeschke added this to the C# 9.0 milestone Nov 12, 2025

RexJaeschke added type: feature This issue describes a new feature Review: pending Proposal is available for review labels Nov 12, 2025

BillWagner added the meeting: discuss This issue should be discussed at the next TC49-TG2 meeting label Feb 17, 2026

BillWagner self-assigned this Feb 17, 2026

BillWagner removed the meeting: discuss This issue should be discussed at the next TC49-TG2 meeting label Mar 11, 2026

BillWagner force-pushed the v9-unconstrainted-type-parameter branch from 1fbcb02 to 30b3684 Compare April 10, 2026 21:56

BillWagner force-pushed the v9-unconstrainted-type-parameter branch from 30b3684 to 995251f Compare May 12, 2026 22:01

BillWagner force-pushed the v9-unconstrainted-type-parameter branch from 995251f to aa52bc5 Compare June 24, 2026 17:36

BillWagner added the meeting: discuss This issue should be discussed at the next TC49-TG2 meeting label Jul 16, 2026

jskeet requested a review from a team July 22, 2026 19:59

BillWagner mentioned this pull request Jul 22, 2026

Specify version specific branch #1745

Merged

RexJaeschke and others added 3 commits July 24, 2026 10:57

Update classes.md

bfecb3b

Review and update

62301d7

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 bbc5ca5 to 62301d7 Compare July 24, 2026 19:50

fix md

1d3c0df

jskeet reviewed Jul 29, 2026

View reviewed changes


		Because `unmanaged` is not a keyword, in primary_constraint the unmanaged constraint is always syntactically ambiguous with class_type. For compatibility reasons, if a name lookup ([§12.8.4](expressions.md#1284-simple-names)) of the name `unmanaged` succeeds it is treated as a `class_type`. Otherwise it is treated as the unmanaged constraint.

		The `default` constraint applies to a type parameter whose inherited constraints do not establish it as a reference type or a value type; its effect on `T?` in override methods and explicit interface method implementations is specified in [§15.6.5](classes.md#1565-override-methods) and [§19.6.2](interfaces.md#1962-explicit-interface-member-implementations).

Uh oh!

Conversation

BillWagner commented Nov 11, 2025

Uh oh!

BillWagner commented Feb 17, 2026

Uh oh!

BillWagner commented Jun 24, 2026

Uh oh!

BillWagner commented Jul 16, 2026

Uh oh!

jskeet commented Jul 17, 2026

Uh oh!

jskeet commented Jul 22, 2026

Uh oh!

jskeet left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants