fmap/bind and/or LINQ support for nullable types

[delreluca]

Hi,

I tend to think of nullable types as option types (Maybe T in Haskell, T option in F#, etc.).

While for nullable value types we can add extension methods, nullable reference types are a language feature instead of a type, thus we cannot offer functor/monad functionality via Select and SelectMany methods (which would yield automatic LINQ support as well).

One of the strengths of option types is to ignore the possibility of a missing value and perform calculations via functorial map, until the value is actually needed at which point now I have to deal with possibly missing values (a GetOrElse method would also be a nice addition to nullable reference types here by the way).

The same holds for operations in between that also may fail (T -> T? typed), which are applied via monadic bind.

I'm new to C# language discussions, so I'm not sure what is the best way to achieve this.

One could 1:1 map the language feature to a type (which should offer similar methods as Option<T> from language-ext), or without mapping it to a type, special LINQ support could be enabled for nullable reference types.

I would envision something like this

string? maybeS; // from outside
string f(string x) => x.ToUpper();
string? g(string y) => y.Length > 2 ? y.Substring(2) : null;

// Select
string? maybeFS = from s /* : string */ in maybeS // : string?
                  select f(s) /* : string */;

// SelectMany
string? maybeGFS = from fS /* : string */  in maybeFS // : string?
                   from gFS /* : string */ in g(fS) // : string?
                   select gFS /* : string */;

// Which could be actually combined into:
string? maybeGFS2 = from s /* : string */ in maybeS // : string?
                    from gFS /* : string */ in g(f(s)) // : string?
                    select gFS /* : string */;

Which can be translated into Select/SelectMany just as any other LINQ query, if we map to a type. If we choose to not map to a type these queries should translate into

var maybeFS = maybeS is null ? null : f(maybeS!);

var maybeGFS = maybeFS is null ? null : g(maybeFS!);

Looking forward to your opinions.

[HaloFour]

To sum up, you're looking for the ability to define extension methods that would be applicable only to instances of a nullable reference type?

I think that would be a bit complicated as despite being called "Nullable Reference Types" they're not actual types and the nullability can flip based on usage. So, my questions would be:

1. How would this apply in #nullable disable context?
2. Would the extension method no longer be in scope if flow-analysis determines that the variable is not nullable in that situation?

   string? s = SomeMethod();
   s.ExtensionMethod(); // type is "string?" here, extension method is in scope
   if (s != null) {
       s.ExtensionMethod(); // type is "string" here, is extension method still in scope?
   }

[delreluca]

Using extension methods would be one of the two ways I was thinking of, but I actually was not arguing for user-defined extension methods, only internally pre-defined Select/SelectMany extensions. The other way I propose is to translate LINQ queries for nullables differently, namely into if-cascades (or ternary operator cascades).

Regarding your questions:

1. In a disabled context everything is nullable, so Select/SelectMany have no added value. I would disable them.
2. Again in the case that s is known to be not null Select/SelectMany do not offer any added value. s.Select(f) would just be f(s) as s? (not sure if the as is even legal, I hope you get what I mean) and s.SelectMany(g) would be g(s).

[HaloFour]

Those methods would be coming from the BCL and they can't be conditionally defined in such a manner. Either a class has the method or it doesn't.

IMO NRTs aren't a good way to model Option/Maybe monads. NRTs are intended to be a linter and not change behavioral semantics of the language. To have a "method" appear or disappear based on the nullability would break that, especially as the flow analysis may be tweaked over time. I'd suggest that when ADTs/DUs are added to the language that they will be a better way to model Option/Maybe.

[delreluca]

You are right, ADTs are the obvious solution and I’m hyped for them. I wanted to tackle the problem of “legacy” (non-ADT) code here.

Let’s assume we had ADTs, would there be a way to promote T? to Option<T>, either automatically or manually (but in a concise way without clutter)?

[333fred]

Let’s assume we had ADTs, would there be a way to promote T? to Option, either automatically or manually (but in a concise way without clutter)?

Theoretically, yes, you should be able to define an implicit conversion to one. You might start to run into some odd corners around interfaces however, as user defined conversions do not apply to interface types. A better solution might be an extension ToOption method that accepts a nullable input and returns a Some T or None depending on input.

[quinmars]

I think this is already possible, see this example

using System;

#nullable enable

public class C {
    public void M() {
        string? maybeS = null;
        string f(string x) => x.ToUpper();
        
        var result = from s in maybeS
            select f(s);
            
        var result2 = f(maybeS); // CS8604: Possible null reference argument for parameter
    }
}

public static class Extensions
{
    public static TRet? Select<T, TRet>(this T? input, Func<T, TRet> selector)
        where T : class where TRet : class
    {
        if (input is null)
            return default;
        
        return selector(input);
    }
}

[HaloFour]

@quinmars

That does work, but it doesn't limit the extension method to cases where the variable is maybe-null.

[quinmars]

It compiles when you are using the System.Linq namespace.

[delreluca]

You're right I was speaking too fast, I'm sorry. Let me think about whether there are other potential ambiguities.

[delreluca]

The following strikes me as counter-intuitive:

// with using System.Linq;

IEnumerable<int> xs = new int[2] {1,2};
var ys = xs.Select(x => new [] {x}); // type IEnumerable<int>[]? instead of IEnumerable<int[]>