Proposal: user-defined null/default check (non-defaultable value types / nullable-like types)

[ufcpp]

Nullable types - Nullable<T> or any reference types - are specially treated with some syntax:

• propagate an invalid value with a ?. operator
• serve an alternative value with a ?? operator
• [planned] Flow-analysis based validity checking like non-nullable reference types

There are some types behaving like nullable types, and I would like these "nullable-like" types to be "first-class" in terms of special treatment like ?., ??, and flow-analysis.

Nullable-like types examples

1. value-constrained struct

Suppose that you implement a type which value has some constraints: for instance, an integer type which is constrained to be positive:

struct PositiveInt
{
     public int Value { get; }
     public PositiveInt(int value)
    {
        if (value <= 0) throw new InvalidOperationException();
        Value = value;
    }
}

If C# compiler would have DbC and record types, this sample would be written like:

struct PositiveInt(int Value) requires Value > 0;

This struct is meant not to be zero or less, but can be zero if and only if using default(PositiveInt). The default should be treated as an invalid value like null.

2. Expected

There is a problem with using null as an invalid value, it does not tell why the operation returned null. To solve this problem, some people 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; }
    public bool HasValue => Exception == null;
}

When I use such a type, I want to write as following:

Expected<string> s;
Expected<int> len = s?.Length;
int x = len ?? 0;

This code uses "exception propagating operator" ?. and "exception coalescing operator" ?? by analogy with null propagating/coalescing operator.

Proposed syntax

I want some syntax to introduce "nullable-like" types to C#; One idea is "operator null":

// definition
struct Expected<T>
{
    public T Value { get; }
    public Exception Exception { get; }
    public static bool operator null => Exception != null;
}

// usage
Expected<int> e;
int x = e ?? 0;

// generated code
Expected<int> e;
int x = operator null(e) ? 0 : e.Value;

[dsaf]

So it's like an Option type but with error details + syntax sugar? Can't we use a tuple and an extension method?

(int result, Exception error) len = s?.Length;
int x = len.GetValueOrDefault();

public static T GetValueOrDefault<T>(this (T Result, Exception Error) source, T defaultValue = default(T))
{
    return source.Error == null ? source.Result : defaultValue;
}

[dsaf]

Scala has few ways:

http://www.scala-lang.org/api/2.9.3/scala/Either.html

http://blog.xebia.com/try-option-or-either/

[alrz]

@dsaf This is Result in Rust and FSharpResult in F#.

[dsaf]

@alrz any decent modern language basically :). So a CoreFX issue unless we want the ?? operator? They already have this https://github.com/dotnet/corefx/issues/538 but sadly it's just the presence/absence - no error details.

[DavidArno]

There already exists a proposed (and possibly still planned) feature that would address this requirement: the is operator for patterns. By changing your type to:

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

    public static bool operator is(Expected<T> e, out T v)
    {
        v = Exception == null ? Value : default(T);
        return  Exception == null;
    }
}

Then you'd be able to do:

Expected<int> e;
int x = e is int ? e.Value : 0;

Or, using the new "is var" scope leakage, and the proposed wildcard feature, it just becomes:

Expected<int> e;
_ = e is int x;
// x will either be default(int) or e.Value here

[HaloFour]

I don't like the idea of conflating null with this concept. An Expected<T> with an exception isn't null.

If the primary goal is to support the ?. and ?? operators then perhaps both can be supported by convention. For example, if the type has a HasValue property (or HasValue() extension method, unless extension properties become a thing), then it would be pretty easy to support both operators. The ?? operator could be further supported by a GetValueOrDefault(T) method, although that wouldn't be strictly necessary.

[alrz]

I smell monad ...

It'd nice to see a proposal for defining monad's operators to cover all these cases. HasValue convention would only work for handling value absence. But I think it'd worth to explore a general solution for these kind of things. As far as I remember someone implemented null check with task-like types e.g. await does the null check and returns early in case of the value null, however, awaitables aren't really a suitable mechanism to implement such behavior.

It's funny that Rust uses ?. operator on Result type for exactly this purpose.

https://github.com/rust-lang/rfcs/blob/master/text/0243-trait-based-exception-handling.md

[ufcpp]

@dsaf Yes, Option is also the example. I also wish we can use tuples and extensions.

[ufcpp]

Some more examples:

• Option or Maybe where T can be both reference and value type in contrast to Nullable where T : struct
• Thin wrapper structs such as TaskAwaiter which should contain a non-null reference
• UnityEngine.Object overloads operator true and == with which a value is treated as null if internal native resources have been disposed

[ufcpp]

To tell the truth, what I want the most is "non-default value types".

[ufcpp]

default(T) makes null where T is struct and contains members of reference types. Thus, if C# would have non-null reference analysis, C#should have non-default value analysis too.

[HaloFour]

There's nothing special about default(T). All C# does is have the CLR zero-init that memory. The net effect of that is that reference types are null, including those as fields of a value type. This is all C# or the CLR can do when it doesn't know what T is.

[ufcpp]

@HaloFour Non-nullable reference types in C# vNext is based on flow analysis. This analysis should contain "defaultability" of value types.

[HaloFour]

I see what you're saying. However, in most cases a default value type is perfectly fine and it doesn't make sense to bother warning on them. I think that there would be a lot of potential value in allowing for analyzers to potentially tap into the flow analysis so that custom types like Option<T> or whatever could participate, but I can't see there being a general purpose rule here.

[svick]

@alrz I don't think this should go full monad. For example, consider the IEnumerable<T>/sequence monad. I would be very surprised if e. g. ImmutableArray.Create(1, 2, 3)?.ToString() returned IEnumerable<string> or ImmutableArray<string>.

To me, the ?. operator only makes for types that can have zero or one values, not more. And HasValue should be sufficient for that.

(Plus I'd say it's consistent with LINQ, which technically does go full monad, but is not used that way in practice, and is strongly biased towards the sequence monad.)