Specify generic constraints added to support nullable reference types in C# 8 #1178

BillWagner · 2024-09-18T15:44:49Z

Add the class? and notnull constraint.

The default constraint is added in C# 9, so is not included.

Bring in the normative text from dotnet#700. Some text is removed because of the decision on normative language in our September meeting.

BillWagner · 2024-09-18T20:44:58Z

@jskeet I added the meeting discuss label on this. I doubt that it's final, but it's worth a first look.

KalleOlaviNiemitalo · 2024-09-19T04:01:10Z

standard/classes.md

    | 'unmanaged'
    ;

 secondary_constraints
-    : interface_type
+    : interface_type '?'?
    | type_parameter


Shouldn't secondary_constraints allow type_parameter ? as the first secondary constraint? Seems strange to only allow the ? in subsequent secondary constraints. E.g.

public class C<T, U, V> where T : U?, V { }

vs.

public class C<T, U, V> where T : U, V? { }

standard/classes.md

KalleOlaviNiemitalo · 2024-09-19T04:08:37Z

standard/types.md

@@ -532,7 +532,7 @@ type_argument
    ;
 ```

-Each type argument shall satisfy any constraints on the corresponding type parameter ([§15.2.5](classes.md#1525-type-parameter-constraints)).
+Each type argument shall satisfy any constraints on the corresponding type parameter ([§15.2.5](classes.md#1525-type-parameter-constraints)). A type argument whose nullability doesn't match the nullability of the type parameter satisfies the constraint with the exception that a nullable value type does not satisfy the struct constraint. A warning may be issued when the nullability of a type argument does not satisfy the nullability requirements of the constraint.


Does not satisfy the value type constraint. struct is the keyword in the constraint syntax but it's not the name of the constraint.

KalleOlaviNiemitalo · 2024-09-19T04:12:34Z

standard/types.md

 ```

+The *non_nullable_non_value_type_parameter* in *nullable_type_parameter* shall be a type parameter that isn’t constrained to be a value type.


"shall" can give the wrong idea that the compiler would report an error otherwise. Could clarify with a note saying that the same syntax can be used with a type parameter that is constrained to be a value type, but it means Nullable<T> in that case.

Also waiting for more eyes here. I see your point, but I don't have the right suggestion yet.

KalleOlaviNiemitalo · 2024-09-19T04:23:07Z

standard/types.md

 ```

+The *non_nullable_non_value_type_parameter* in *nullable_type_parameter* shall be a type parameter that isn’t constrained to be a value type.
+
+In *nullable_type_parameter*, the annotation `?` indicates the intent that type arguments of this type are nullable. The absence of the annotation `?` indicates the intent that type arguments of this type are non-nullable.


I'm not sure that the intention is for the type argument to be nullable.

class C { void M<T>() where T : class { T?[] a = {}; } void N() { M<object>(); } }

In the declaration T?[] a = {};, T? is a nullable_type_parameter. The corresponding type argument is object in M<object>();, but that one isn't nullable.

On second thought, I'm not sure T? is a nullable_type_parameter after all. It matches the nullable_type_parameter grammar but nullable_type_parameter doesn't seem to be referenced by any other grammar rule, so it is not applicable in this context (nor in any other).

I'm waiting for others to weigh in here as well. I see your point, but I don't have an obvious suggestion yet.

jskeet · 2024-09-19T09:30:52Z

(I'll wait for responses to @KalleOlaviNiemitalo's questions before reviewing, if that's okay.)

Nigel-Ecma

Some comments plus ANTLRizing some grammar rules.

I haven’t considered per se what should (not) be in the Standard in regards to the specification of NRT.

Nigel-Ecma · 2024-09-20T20:23:42Z

standard/classes.md

+    : interface_type '?'?
+    | type_parameter '?'?
+    | secondary_constraints ',' interface_type '?'?
+    | secondary_constraints ',' type_parameter '?'?


I think we should review the grammar here. I can't add this as a suggested changed as it covers non-altered lines, so just code. The rules here pre-date the use of ANTLR, if we ANTLRize them and remove unneeded left-recursion (as we do elsewhere) we get:

type_parameter_constraints : primary_constraint (',' secondary_constraints)? (',' constructor_constraint)? | secondary_constraints (',' constructor_constraint)? | constructor_constraint ; primary_constraint : class_type '?'? | 'class' '?'? | 'struct' | 'notnull' | 'unmanaged' ; secondary_constraint : interface_type '?'? | type_parameter '?'? ; secondary_constraints : secondary_constraint (',' secondary_constraint)* ;

Optionally to improve readability we could replace the '?'? by adding a rule:

nullable_type_attribute : '?' ; type_parameter_constraints : primary_constraint (',' secondary_constraints)? (',' constructor_constraint)? | secondary_constraints (',' constructor_constraint)? | constructor_constraint ; primary_constraint : class_type nullable_type_attribute? | 'class' nullable_type_attribute? | 'struct' | 'notnull' | 'unmanaged' ; secondary_constraint : interface_type nullable_type_attribute? | type_parameter nullable_type_attribute? ; secondary_constraints : secondary_constraint (',' secondary_constraint)* ;

The introduced * nullable_type_attribute* would then also need to be used in other grammar rules where the literal '?' is used as a type attribute and not in places where it is not, e.g. for the null conditional operations.

I like the second one. When I was working through the grammar, I found '?'? hard to mentally parse and read through the grammar.

+1 for a rule for nullable_type_attribute.

Nigel-Ecma · 2024-09-20T20:28:21Z

standard/classes.md


-A secondary constraint can be a *type_parameter* or *interface_type*.
+A secondary constraint can be a *type_parameter* or *interface_type*, either optionally followed by `?`.


This doesn’t read well to me in this context, given the comment on 426 above I’ll offer two alternatives:

Suggested change

A secondary constraint can be a *type_parameter* or *interface_type*, either optionally followed by `?`.

A secondary constraint can be a *type_parameter* or *interface_type*, either optionally nullable.

Or if the line 426 added rule is adopted:

Suggested change

A secondary constraint can be a *type_parameter* or *interface_type*, either optionally followed by `?`.

A secondary constraint can be a *type_parameter* or *interface_type*, optionally followed by a *nullable_type_attribute*.

Nigel-Ecma · 2024-09-20T20:42:23Z

standard/classes.md

+A type parameter is *known to be a non-nullable reference type* if it has the non-nullable reference type constraint or its effective base class is not `object` or `System.ValueType`.
+
+A type parameter is *known to be a reference type* if it has the non-nullable reference type constraint, reference type constraint or its effective base class is not `object` or `System.ValueType`.


Could this be simplified to:

Suggested change

A type parameter is *known to be a non-nullable reference type* if it has the non-nullable reference type constraint or its effective base class is not `object` or `System.ValueType`.

A type parameter is *known to be a reference type* if it has the non-nullable reference type constraint, reference type constraint or its effective base class is not `object` or `System.ValueType`.

A type parameter is *known to be a non-nullable reference type* if it has the non-nullable reference type constraint or its effective base class is not `object` or `System.ValueType`.

A type parameter is *known to be a reference type* if it has the reference type constraint or its known to be a non-nullable reference type.

its => it's in the suggestion (line 614) - but then I like it.

I think we're not to use contractions, so "it is".

Nigel-Ecma · 2024-09-20T20:57:38Z

standard/classes.md

@@ -878,7 +885,7 @@ All members of a generic class can use type parameters from any enclosing class,
 > class C<V>
 > {
 >     public V f1;
->     public C<V> f2 = null;
+>     public C<V> f2 = null!;


It is unclear to me why in the original f2 was initialised, and f1 not, when both are set in the constructor. Now a suppression has been added…

I suggest a comment explaining the suppression, or the use of default (which leaves the explanation for the section on default to handle), or just drop the initialisation.

I think it would be better to drop the initialization.

Nigel-Ecma · 2024-09-20T22:55:57Z

standard/types.md

@@ -532,7 +532,7 @@ type_argument
    ;
 ```

-Each type argument shall satisfy any constraints on the corresponding type parameter ([§15.2.5](classes.md#1525-type-parameter-constraints)).
+Each type argument shall satisfy any constraints on the corresponding type parameter ([§15.2.5](classes.md#1525-type-parameter-constraints)). A type argument whose nullability doesn't match the nullability of the type parameter satisfies the constraint with the exception that a nullable value type does not satisfy the value type constraint. A warning may be issued when the nullability of a type argument does not satisfy the nullability requirements of the constraint.


I don’t think this needs to be phrased in terms of value type exceptions, the point being that reference type nullability is a “soft” constraint. Maybe:

Suggested change

Each type argument shall satisfy any constraints on the corresponding type parameter ([§15.2.5](classes.md#1525-type-parameter-constraints)). A type argument whose nullability doesn't match the nullability of the type parameter satisfies the constraint with the exception that a nullable value type does not satisfy the value type constraint. A warning may be issued when the nullability of a type argument does not satisfy the nullability requirements of the constraint.

Each type argument shall satisfy any constraints on the corresponding type parameter ([§15.2.5](classes.md#1525-type-parameter-constraints)). A reference type argument whose nullability doesn’t match the nullability of the type parameter satisfies the constraint; however a warning may be issued.

I see that @KalleOlaviNiemitalo has commented on the use of “shall” here, I'll defer that to @RexJaeschke.

Nigel-Ecma · 2024-09-20T23:07:47Z

standard/types.md

+
+nullable_type_parameter
+    : non_nullable_non_value_type_parameter '?'
+    ;
+
+non_nullable_non_value_type_parameter
+    : type_parameter
+    ;


This grammar is wrong/pointless, as @KalleOlaviNiemitalo has commented the added rules are not used anywhere.

Unfortunately I’m not sure what the intended semantics are here.

Guessing: is the addition of the nullable type attribute meant to require the type argument to be a nullable reference and/or value type, i.e. it’s an additional kind of primary_constraint or secondary_constraint?

That was my mistake. I added the additional rules in the latest commit.

Note that the grammar additions for non_nullable_reference_type and nullable_reference_type are in #1089

jskeet

I like Nigel's suggestions in general. My guess is that the currently-unused rules are intended to be used in the future? Would be good to know.

jskeet · 2024-09-25T14:59:12Z

standard/classes.md

+    : interface_type '?'?
+    | type_parameter '?'?
+    | secondary_constraints ',' interface_type '?'?
+    | secondary_constraints ',' type_parameter '?'?


+1 for a rule for nullable_type_attribute.

jskeet · 2024-09-25T15:04:26Z

standard/classes.md

+A type parameter is *known to be a non-nullable reference type* if it has the non-nullable reference type constraint or its effective base class is not `object` or `System.ValueType`.
+
+A type parameter is *known to be a reference type* if it has the non-nullable reference type constraint, reference type constraint or its effective base class is not `object` or `System.ValueType`.


its => it's in the suggestion (line 614) - but then I like it.

jskeet · 2024-09-25T15:05:46Z

standard/classes.md

@@ -878,7 +885,7 @@ All members of a generic class can use type parameters from any enclosing class,
 > class C<V>
 > {
 >     public V f1;
->     public C<V> f2 = null;
+>     public C<V> f2 = null!;


I think it would be better to drop the initialization.

BillWagner · 2024-09-25T15:28:35Z

@jskeet

My guess is that the currently-unused rules are intended to be used in the future? Would be good to know.

Which rules do you think are unused? I didn't see any.

jskeet · 2024-09-25T15:34:10Z

@jskeet

My guess is that the currently-unused rules are intended to be used in the future? Would be good to know.

Which rules do you think are unused? I didn't see any.

non_nullable_non_value_type_parameter and nullable_type_parameter - see Nigel's comments.

BillWagner · 2024-09-25T17:34:17Z

@jskeet

My guess is that the currently-unused rules are intended to be used in the future? Would be good to know.

Which rules do you think are unused? I didn't see any.

non_nullable_non_value_type_parameter and nullable_type_parameter - see Nigel's comments.

Got it. I'd missed some edits. See latest commit.

standard/types.md

Co-authored-by: Nigel-Ecma <perryresearch@zoot.net.nz>

BillWagner added 3 commits September 18, 2024 11:43

Incorporate some text from dotnet#700

c2bb8dd

Bring in the normative text from dotnet#700. Some text is removed because of the decision on normative language in our September meeting.

fix build issues

29dc043

Edit pass

39e136a

BillWagner marked this pull request as ready for review September 18, 2024 20:44

BillWagner added the meeting: discuss This issue should be discussed at the next TC49-TG2 meeting label Sep 18, 2024

KalleOlaviNiemitalo reviewed Sep 19, 2024

View reviewed changes

Respond to feedback.

98d3f1d

Nigel-Ecma requested changes Sep 20, 2024

View reviewed changes

jskeet reviewed Sep 25, 2024

View reviewed changes

port grammar, part 1

cdd12d4

Nigel-Ecma reviewed Sep 25, 2024

View reviewed changes

standard/types.md Outdated Show resolved Hide resolved

Update standard/types.md

b8b3545

Co-authored-by: Nigel-Ecma <perryresearch@zoot.net.nz>

Nigel-Ecma mentioned this pull request Sep 25, 2024

Different reference types: nullable and non-nullable #1124

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Specify generic constraints added to support nullable reference types in C# 8 #1178

Specify generic constraints added to support nullable reference types in C# 8 #1178

BillWagner commented Sep 18, 2024

BillWagner commented Sep 18, 2024

KalleOlaviNiemitalo Sep 19, 2024

KalleOlaviNiemitalo Sep 19, 2024

KalleOlaviNiemitalo Sep 19, 2024

BillWagner Sep 20, 2024

KalleOlaviNiemitalo Sep 19, 2024

KalleOlaviNiemitalo Sep 19, 2024 •

edited

Loading

BillWagner Sep 20, 2024

jskeet commented Sep 19, 2024

Nigel-Ecma left a comment

Nigel-Ecma Sep 20, 2024

BillWagner Sep 23, 2024 •

edited

Loading

jskeet Sep 25, 2024

Nigel-Ecma Sep 20, 2024

Nigel-Ecma Sep 20, 2024

jskeet Sep 25, 2024

BillWagner Sep 25, 2024

Nigel-Ecma Sep 20, 2024

jskeet Sep 25, 2024

Nigel-Ecma Sep 20, 2024

Nigel-Ecma Sep 20, 2024

BillWagner Sep 25, 2024

jskeet left a comment

jskeet Sep 25, 2024

jskeet Sep 25, 2024

jskeet Sep 25, 2024

BillWagner commented Sep 25, 2024

jskeet commented Sep 25, 2024

BillWagner commented Sep 25, 2024

		```

		The non_nullable_non_value_type_parameter in nullable_type_parameter shall be a type parameter that isn’t constrained to be a value type.


		A secondary constraint can be a type_parameter or interface_type.
		A secondary constraint can be a type_parameter or interface_type, either optionally followed by `?`.

		A type parameter is known to be a non-nullable reference type if it has the non-nullable reference type constraint or its effective base class is not `object` or `System.ValueType`.

		A type parameter is known to be a reference type if it has the non-nullable reference type constraint, reference type constraint or its effective base class is not `object` or `System.ValueType`.

Specify generic constraints added to support nullable reference types in C# 8 #1178

Are you sure you want to change the base?

Specify generic constraints added to support nullable reference types in C# 8 #1178

Conversation

BillWagner commented Sep 18, 2024

BillWagner commented Sep 18, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

KalleOlaviNiemitalo Sep 19, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jskeet commented Sep 19, 2024

Nigel-Ecma left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

BillWagner Sep 23, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jskeet left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

BillWagner commented Sep 25, 2024

jskeet commented Sep 25, 2024

BillWagner commented Sep 25, 2024

KalleOlaviNiemitalo Sep 19, 2024 •

edited

Loading

BillWagner Sep 23, 2024 •

edited

Loading