C# 11 / .NET 7 - nullability behavior after "is" check for Nullable<value type>

Question

I have been using the is operator liberally in projects with nullable reference types:

    // Works just fine
    public CheckClass Foo(CheckClass? arg)
    {
        return arg is CheckClass
            ? arg
            : new();
    }

However, this throws a compile-time error:

    // Cannot convert 'int?' to 'int'
    public int Bar(int? arg)
    {
        return arg is int
            ? arg
            : 0;
    }

It's easy enough to fix by using the .Value property on arg. And as I understand it, nullable reference types are a "soft" compile-time verification, while Nullable<T> is a "hard" generic class.

Still, it's a bit galling, and seems strange since Nullable<T> gets preferential treatment in a lot of cases. The is expression is perfectly capable of checking for the existence of a value, for one thing, and can produce a non-nullable object of the equivalent type, if it is given a name.

    // Noooo problem
    public int Bar(int? arg)
    {
        return arg is int val
            ? val
            : 0;
    }

Was this behavior explicitly chosen, or is it an oversight? If it's the former, what might be the reasoning behind it?

Answer 1

Was this behavior explicitly chosen, or is it an oversight? If it's the former, what might be the reasoning behind it?

Basically yes, it was explicitly chosen. The design team decided not to represent nullable reference types (introduced with C# 8) as a separate type as it was done with nullable value types (introduced in .NET Framework 2.0) with Nullable<T>. So from compiler point of view nullable reference type is basically is a bunch of metainfromation which is analyzed at compile time, while nullable value types in this case require type conversions.

This leads to the observed behavior which has more minimalistic repro:

int? tempV = null;
object? tempO = null;

// int v = tempV; // Compilation error: Cannot implicitly convert type 'int?' to 'int'
object o = tempO; // warning, depends on the compiler settings

This is obviously is not ideal and leads to several other problems - like unconstrained generic handling with nullable types.

The is expression is perfectly capable of checking for the existence of a value, for one thing, and can produce a non-nullable object of the equivalent type, if it is given a name.

Yes, because compiler recognizes it as basically a null check and transforms it to something like:

internal static int Bar(Nullable<int> arg)
{
    if (arg.HasValue)
    {
        return arg.GetValueOrDefault();
    }
    return 0;
}

See for more info - Type testing with pattern matching and Pattern matching docs.

Notes:

• Compiler will infer the type returned by ternary operator based on types used in it. In second case you have int? and int so int? is inferred, hence the compilation error.
• The Bar method is basically Nullable<T>.GetValueOrDefault, consider using it instead. Or just use the null-coalescing operator - arg ?? 0.
• See also - Why does nullability check not work with value types?

Answer 2

Nullable value types have been around longer than nullable reference types. Thus,

int? arg = ...;
var x = arg is int ? arg : 0;

has always yielded an expression of type int?, not int, for x. Changing it to return an int (to be consistent with nullable reference types) would be a breaking change:

int? arg = ...;
var x = arg is int ? arg : 0;

// This code, which worked before, would break if a new version of the
// compiler decided to type `x` as an `int` instead of an `int?`.
int y = x.Value;