Proposal: nullable-like types

[ufcpp]

Ported from dotnet/roslyn#15108

nullable-like types

Summary

Reference types and Nullable<T> have a special position that they can be use ?. and ?? operators. However, we sometimes want to use these operators on other types. ?. and ?? should be generalized to arbitrary types with pattern-based approach.

Motivation

Example 1: UnityEngine.Object

UnityEngine.Object - a common base type in Unity Game Engine - overloads operator == with which a value is treated as null (x == null is true) if internal native resources have been disposed.

However, ?. and ?? for reference types does not call operator ==. Instead, the C# compiler emits a brtrue instruction which simply checks nullability by reference. Thus, ?. and ?? on UnityEngine.Object doesn't work properly:

int? X(UnityEngine.Object obj)
{
    // OK
    if (obj == null) return null;
    return obj.GetInstanceID();
}

// runtime exception: the native resource is disosed
int? Y(UnityEngine.Object obj) => obj?.GetInstanceID();

So far, this is not so big problem because Unity uses C# 3.0. However, Unity 5.5 will update C# to 6.0. That behavior of ?. operator could be a pitfall.

Example 2: Expected<T>

A certain number of developers tend to avoid using null as an invalid value. A reason of it is that null doesn't tell us why a result became invalid. To solve this problem, they prefer a type similar to expected<T> in C++ - it is a union type of T and Exception as following:

struct Expected<T>
{
    public T Value { get; }
    public Exception Exception { get; }
}

If C# would have a type like this, ?. and ?? might be allowed on the type.

Expected<string> x = new Expected<string>(new Exception());
Expected<int> y = x?.Length;
string z = x ?? "";

Proposal

I propose that ?. and ?? operators can be used on types that implement certain pattern. I call these types "nullable-like types" named after task-like. How about the pattern like:

struct NullableLike<T>
{
    public T Value { get; }
    public bool HasValue { get; }
    // propagate a valid value
    public NullableLike<U> Propagate<U>(U value);
    // propagate an invalid value
    public NullableLike<T> Propagate();
}

For example, the Expected<T> could implement this pattern as follows:

struct Expected<T>
{
    public T Value { get; }
    public Exception Exception { get; }

    public Expected(T value)
    {
        Value = value;
        Exception = null;
    }
    public Expected(Exception exception)
    {
        Value = default(T);
        Exception = exception;
    }

    public bool HasValue => Exception == null;
    public Expected<U> Propagate<U>() => new Expected<U>(Exception);
    public Expected<U> Propagate<U>(U value) => new Expected<U>(value);
}

Now, the sample of Expected<T> described in the previous section is expanded as follows:

Expected<string> x = new Expected<string>(new Exception());
Expected<int> y = x.HasValue ? x.Propagate(x.Value.Length) : x.Propagate<int>();
string z = x.HasValue ? x.Value : "";

Alternatives

There are some alternative approaches that use query expressions and task-like.

[orthoxerox]

See also dotnet/roslyn#4347

[YaakovDavis]

I think Lift might be a better name to Propagate, as it's commonly used in such contexts.

[richardtallent]

Changing the semantics of ?. and ?? to trigger on non-null values would be a significant change.

For the case of ??, since the proposal doesn't suggest modifying any native types, you could overload the || operator and use it instead of ??:

public class Person {
    public string Name { get; set; }
    public bool HasValue => !string.IsNullOrEmpty(Name);
    public static person operator |(Person p1, Person p2) {
        if(p1==null) return p2;
        return p1.HasValue ? p1 : p2;
    }
    public static bool operator true(Person p) => p != null && p.HasValue;
    public static bool operator false(Person p) => p == null || !p.HasValue;
}

...
Person p1 = null;
var p2 = new Person() { Name = string.Empty };
var p3 = new Person() { Name = "Alice" };
var p = p1 || p2 || p3;
Console.WriteLine(p.Name);    // Alice
var p4 = p1 || p2;
Console.WriteLine(p4.Name);    // ""

Using || to coalesce not only null but invalid values to a new default value is a familiar sight in ECMAScript, so I think it would be easy for developers to grok. I've proposed this as an alternative in #183 to creating a new operator ??? to handle defaulting null-or-empty states, and for everything but native types, can be implemented without changing the language or runtime.

If we go down the road of having ?? and ?. switch on something other than null, I think an explicit interface would be preferred to duck-typing on HasValue. Or, we could simply have it check for the false operator and use it rather than just a null check, so there's no need for a new specially-named member.

[jnm2]

Couldn't this change the meaning of existing code? I'd prefer to have to explicitly opt in per type by defining a ?? operator.

[Richiban]

@jnm2 I don't think it will, since using the ?? or ?. operators with a value type on the left-hand side is currently a compiler error, so it's not a breaking change.

The C# compiler does already do some duck-typing, such as foreach or await, so there's precedent for this proposal.

[jnm2]

@Richiban That's correct if it only applies to value types, but the example was given of the UnityEngine.Object base type, so I assumed it was supposed to work on reference types too.

[ufcpp]

In the Nullable reference types proposal, T? is just an annotation and T and T? can not be distinguished at reflection, overload resolution, and so on. This design is reasonable enough and I agree with it. However, I wanted to create my own strongly-typed Optional<T> struct. This could be implemented like the following:

// A strongly typed wrapper for T?
public readonly struct Optional<T>
    where T : class
{
    private readonly T? _value;

    public Optional(T value) => _value = value;

    public bool HasValue => _value != null;
    public T Value => _value ?? throw new InvalidOperationException("Optional object must have a value.");
    public T? GetValueOrDefault() => _value;
}

but this struct has some problems:

// comparison to Nullable<T>
static void Nullable()
{
    // convert null to default(int?).
    int? x = null;

    // boxed but no allocation. The CLR optimizes default(int?) to null.
    object? obj = x;

    // null pattern for Nullable<T>.
    if (x is null) Console.WriteLine("is null");

    // unbox from null. The CLR generates default(int?).
    object? @null = null;
    int? y = (int?)@null;

    // null propagating opeartor. x.HasValue ? x.GetValueOrDefault() + 1 : default(int?);
    var z = x + 1;
}

static void MyOptionalWrapper()
{
    // I want compile-time null conversion.
    Optional<string> x = null;

    // I want box optimization to avoid allocation.
    object? obj = x;

    // Iwant null pattern.
    if (x is null) Console.WriteLine("is null");

    // I want runtime null conversion.
    object? @null = null;
    int? y = (int?)@null;

    // I want null propagating opeartor. x.HasValue ? x.GetValueOrDefault() + "abc" : default(Optional<string>);
    var z = x + "abc";
}

So again I want nullable-like types now.

[ufcpp]

A use case: https://gist.github.com/ufcpp/ccb6466415b2e5ccec56f140083659cf

[M-Pixel]

I hope we get this someday. This is one of the primary holes in C#'s "strict" nullability feature.

It's incredibly straightforward.

struct Foo
{
    private readonly string? _value;
    internal Foo(string value)
    {
        _value = value;
    }
}

This sort of thing would be a great way to improve the strength of APIs. GetThing(ThingId id) instead of GetThing(string id). But today, I have a choice - either I have weak typing by using "string" or "int" everywhere, or I lose performance by wrapping small values with reference types, or I have weak nullability because I cannot specify a different understanding of ? for the struct other than "wrap it in a redundant Nullable that might be lying".

[M-Pixel]

However, I'll say, the main issue with the suggested approach is that it's a runtime solution. We need something more like what we have with [MaybeNullWhen]. An attribute that says "this reference-type field represents the "null-ness" of its host struct - when present, ? would not imply Nullable - the nullability-inspecting behaviors of the compiler/analyzer would simply "inline" the representative field when one exists.