C# 8 Nullable reference types: Define different reference types: oblivious, nullable, and non-nullable

[BillWagner]

Related to #700

Fixes #1089

Add text to define the different "flavors" of reference types: "Nullable oblivious" (class reference types), "nullable reference types", and "non-nullable reference types".

Commit history is less clean than I'd like. I'd start thinking that one PR for the contexts #nullable changes and the types would be fine. That was getting larger. So I split the additional changes for #nullable into #1108

[jskeet]

Worth labeling for discussion next week, or is it too early for that?

[BillWagner]

Worth labeling for discussion next week, or is it too early for that?

I'll add the label after making edits. I hope we can discuss it next week.

[BillWagner]

@jskeet @RexJaeschke

As I start on this, I wonder if a separate PR that updates all test examples so they generate the existing output in a nullable context is a good idea. It would separate out that work into one PR to review.

If you both agree, I'll add that PR for Wednesday as well.

[jskeet]

I'm not entirely sure whether that's a good idea. It might end up making a lot of examples that have nothing to do with nullability very null-syntax heavy. But I could be wrong.

Maybe make a start but see how you feel without doing it for all examples?

[KalleOlaviNiemitalo]

The "exact same type" wording feels troublesome. If the ? nullable-reference-type annotation is used in an alias

#nullable enable

using ListOfNullableString = System.Collections.Generic.List<string?>;

class C
{
    // warning CS8619
    System.Collections.Generic.List<string> sl = new ListOfNullableString();
}

then the standard needs some wording to specify that the initializer of the field sl gets both its type and its nullability annotations from the alias ListOfNullableString. Currently, §14.5.2 (Using alias directives) just says "the identifier introduced by the using_alias_directive can be used to reference the given namespace or type" and does not mention nullability.

The alternative would be to specify R and R? as different types that have two-way identity conversions between them, like there are between object and dynamic, or between similar tuple types. But perhaps there's something about flow analysis that makes this not possible.

#nullable enable

class TypeArgumentDeductionWithIdentityConversion
{
    static void OneNrt(string? a, string b)
    {
        N(ref a, ref b); // warning CS8601
    }
    
    static void TwoNrt(string? a, string? b)
    {
        N(ref a, ref b);
    }
    
    static void ObjectVsDynamic(object[] a, dynamic[] b)
    {
        N(ref a, ref b);
    }
    
    static void TupleElementNames((int X, int Y) a, (int Z, int W) b)
    {
        N(ref a, ref b);
    }
    
    static void N<T>(ref T a, ref T b)
    {
    }
}

[BillWagner]

We're thinking that the identity conversion path is the correct one. (We haven't speced out the warning section yet, but there are other identity conversions that can produce warnings).

[RexJaeschke]

@BillWagner As we discussed privately recently, I'm OK with spinning off the examples into a separate PR. I recall there were many, and I applied them in several large commits.

[BillWagner]

As we discussed privately recently, I'm OK with spinning off the examples into a separate PR. I recall there were many, and I applied them in several large commits.

@RexJaeschke @jskeet

I'm leaning that way now too! I updated one sample in this PR because it made sense to show the nullable annotations as part of this PR. That didn't compile in the sample extractor, because nullable was off. Then, when I turned it on, several things failed.

The best way to handle this may be starting with #1106. In that PR, I set the Nullable flag to annotations. Then, as we add other PRs for the nullable reference type feature, we can show it, and it will compile in our test harness. That scopes the changes so that PRs are easier to review.

Then, later, we can change the setting to enable and address any warnings as we see fit.

[BillWagner]

Note: the experiment I tried in this PR and #1106 worked. In #1106, all existing samples compile with the same result as before. And in this PR, I was able to add a nullable annotation where needed. Let's make that the plan of record and move forward.

[BillWagner]

This is causing the section renumber failure. That PR should merge first, then this can be updated as needed.

[BillWagner]

Rex had originally written this to say the default state is "disabled". I prefer implementation defined, so in the future, if the implementation changes, it won't require changing the standard. (Yes, it's already documented for roslyn).

[BillWagner]

@jskeet

Adding the meeting discuss label. I don't think this is ready to merge. But, we should discuss terms, definitions, and concepts so that the edits can be refined after this next meeting.

[jskeet]

We've said they're different types - I think we should reword "same underlying type", but it will require careful wordsmithing. We should see what we say about dynamic.

[Nigel-Ecma]

@jskeet – Does the above say they are different types? We have:

The terms "nullable reference type" and "non-nullable reference type" refer to annotations that declare whether an expression is intended to permit null values or not.

This language suggests there is one type which can have different annotations, not that there are multiple distinct types.

Maybe the term “underlying type” should not be overloaded to deal with (non-)nullable reference types? Given the text is leaning on annotations maybe a better term to use here is “non annotated type” (is it non annotated, nonannotated or unannotated?). This would give:

[…] given a reference type R, the notations R and R? denote the same non annotated type […]

[jskeet]

And a corresponding null-oblivious type? Later on we seem to be treating them as three different types. Let's discuss how we want to describe this, and then try really hard to be consistent.

[BillWagner]

PR #1124 is an alternative that removes the type "null oblivious".
Either this PR or #1124 should be merged.

[Nigel-Ecma]

Overall, as my comments undoubtedly show, I’m not sure it is yet clear what the boundary is between what an implementation (and we probably shouldn't say “compiler” here) must do and may do to be conformant.

[Nigel-Ecma]

@jskeet – Does the above say they are different types? We have:

The terms "nullable reference type" and "non-nullable reference type" refer to annotations that declare whether an expression is intended to permit null values or not.

This language suggests there is one type which can have different annotations, not that there are multiple distinct types.

Maybe the term “underlying type” should not be overloaded to deal with (non-)nullable reference types? Given the text is leaning on annotations maybe a better term to use here is “non annotated type” (is it non annotated, nonannotated or unannotated?). This would give:

[…] given a reference type R, the notations R and R? denote the same non annotated type […]

[BillWagner]

Closing in favor of #1124