Skip to content

[Version 9.0] Feature support for unconstrained type parameter annotations#1470

Draft
BillWagner wants to merge 2 commits intodraft-v9from
v9-unconstrainted-type-parameter
Draft

[Version 9.0] Feature support for unconstrained type parameter annotations#1470
BillWagner wants to merge 2 commits intodraft-v9from
v9-unconstrainted-type-parameter

Conversation

@BillWagner
Copy link
Member

This PR replaces #1326

@RexJaeschke RexJaeschke added this to the C# 9.0 milestone Nov 12, 2025
@RexJaeschke RexJaeschke added type: feature This issue describes a new feature Review: pending Proposal is available for review labels Nov 12, 2025
@BillWagner
Copy link
Member Author

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.

@BillWagner BillWagner added the meeting: discuss This issue should be discussed at the next TC49-TG2 meeting label Feb 17, 2026
@BillWagner BillWagner self-assigned this Feb 17, 2026
- 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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

meeting: discuss This issue should be discussed at the next TC49-TG2 meeting Review: pending Proposal is available for review type: feature This issue describes a new feature

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants