User-defined null on structs

[Perksey]

Summary

In the advent of ref structs, there are now many use cases for which the developer may want to define what "null" means for their struct. For example, users today can write null in place of an expression that evaluates to ReadOnlySpan<T> but this is only because of an implicit operator converting arrays to spans, and converting a null array to a span yields an empty, nullref span. It is likely that the majority of users do not know that this is how null on spans work, and therefore only care for the presence of null for these types of structs.

There may be use cases where user types are unable to wield null as-is as there may be multiple implicit operators that null could be applicable for.

This suggestion is for adding a way for users to control what occurs when a developer writes null for their structs.

Spit-balling here:

public ref struct Maybe
{
    public static implicit operator null() => new Maybe(/* ... */);
}
public ref struct Maybe
{
    public static implicit operator Maybe(null) => new Maybe(/* ... */);
}
public ref struct Maybe
{
    public Maybe(null) => new Maybe(/* ... */);
}

For obvious reasons this should not be allowed for classes.

Motivating Use Case

In SilkX we have wrapper types representing references/pointers, that are implicitly convertible from strings and arrays.

But this isn't the only case, again see Span. The only reason this works today is because of the array operator which feels more of a "happy accident" than a fact known from before the API was designed and/or prototyped.

Our Dirty Workaround

SilkX defines its own little domain specific language extensions, and global using static is used to define a nullptr keyword (actually a static property that returns a NullPtr that implicitly converts to all of these types. JIT does its thing and inlines all of it).

Usage example:

var window = Glfw.CreateWindow(1280, 720, "Hello Window!", nullptr, nullptr);
if (window == nullptr)
{
    ConstPtr<sbyte> error = nullptr;
    if (Glfw.GetError(error.AsPtr2D()) == 0 || error == nullptr)
    {
        throw new Exception("failed to create window and failed to get error");
    }

    throw new Exception($"failed to create window: {error}");
}

Obviously this is extremely cursed, but this is the only way we could think to achieve the developer experience we're after.

[333fred]

@RikkiGibson has looked at things around this area before. There's also several related issues: #146, https://github.com/dotnet/csharplang/blob/main/meetings/2020/LDM-2020-07-01.md#non-defaultable-struct-types, #1981, and #2019.

[HaloFour]

It's been 6 years but I recall Neal also being opposed to the notion of adding more flavors of null to the language: #933 (comment)

[CyrusNajmabadi]

I'm also personally opposed. In a very real sense, i appreciate that when operations are done with null (including things like ?., ??, is null, is not null etc.) i know precisely what semantics that has.

[RikkiGibson]

It's just so much work to make the language and runtime respect a user value type's concept of null. Including when that type is used as a type argument for a T and so on.

I would almost say that we've had several different reasons to want "defaultable value types", "user-defined null on structs", and other highly related scenarios, none of which are compelling enough on their own to do a feature, and which can't all be accommodated by a single design.

[alahijani]

Here is one possible design. The literal null is always of type System.Null, but there is an implicit conversion from System.Null to all reference types.

[TahirAhmadov]

I'm surprised that ReadOnlySpan<T> is implicitly converted to from null. I don't think it should. If you want an empty span, either use ReadOnlySpan<T>.Empty or Array.Empty<T>.

[CyrusNajmabadi]

That's why I said - let's leave Array.Empty aside for a second. Why allow to pass in null, instead of ROS.Empty or default?

Because if i can't pass in a null instance, then i can't do something as simple as this:

public void DoSomethingWithArray<T>(T[]? array) => DoSomethingWithSpan(array);

private void DoSomethingWithSpan<T>(ReadOnlySpan<T> span) { ... }

// later:

DoSomethingWithArray(null);

Now at every point i want to make a span, i can't just pass null in and have it work. I have to actually check what values i have and then use default or ROS.Empty. As i said above: > It literally allows for mapping all arrays into the span world, with zero lots of generality

I dont' want to have to special case null when moving to the span world. That would actively be a bad thing. I want to move to the span world as transparently as possible, without any sort of loss in generality or any new friction added.

[CyrusNajmabadi]

I'm not sure I understand. If the implicit operator simply prohibited nullable array values, then passing in null would generate an NRT warning

Which would be awful. Because now i can't just operate on all arrays uniformly. I have to special case them. Which is an anti goal here. I should be able to work with all arrays, not a subset of them. Span isn't the "we got array wrong, especially null array, so here's an alternative that tried to patch that out" feature. It's the "you can operate on all arrays and any sort of contiguous block of memory uniformly" feature. If you break that, you break the feature.

[CyrusNajmabadi]

If you have int[]? x = ...; and you want to call Foo with either a ROS pointing at x if it's not null, or an empty ROS if x is null, (an unusual requirement) it would be much clearer to do:

1. That's much much much less clear.
2. It requires every point that i'm passing an array to a span to now need this clutter.
3. It adds literal overhead for no purpose.

You're starting from the position that null to a span is somehow a bad thing, and attempting to put up unpleasant roadblocks there. I'm starting from the position that it's uniformly a good thing, and that all these efforts are real impediments that actually get in the way of smooth, streamlined, efficient coding patterns.

[TahirAhmadov]

So basically, this makes it easier to allow accepting spans for existing methods. I understand that goal, but that's a temporary, transitional benefit. Whereas the wart of nulls being convertible to a struct value will stay on forever.

If anything, it should have been designed in a way that a default ROS throws on trying to use it, in which case "converting" null to it maintains the same behavior as before with null-value array references.

That's much much much less clear.

Have to disagree here. We have a uniform rule in C# that structs cannot become nulls, yet we violate that rule here. At the same time, an appropriately named BCL extension method clearly communicates what's going on.

It requires every point that i'm passing an array to a span to now need this clutter.

One extension method call? That's a small price to pay for being explicit and stating clearly what's going on.

It adds literal overhead for no purpose.

Not really, because for example:

static ReadOnlySpan<T> ToROSIfNotNull<T>(this T[]? This)
{
  return This!;
}

This version just wraps around the same implicit operator, and gets optimized away eventually, meaning it's zero overhead.

PS. Also, it looks like too much emphasis on methods expecting a nullable array parameter. I view nullable parameters as more of an exception, not the rule, especially with arrays (or any collections for that matter) - it's a code smell. Most of the time, collections are expected, it should be "not null". Therefore, introducing this null convertibility addresses a scenario which should not be encouraged, which I think is a strange decision.
Oh well....

[CyrusNajmabadi]

We have a uniform rule in C# that structs cannot become nulls,

I don't know what rule you're talking about.

At the same time, an appropriately named BCL extension method clearly communicates what's going on.

My point is: i don't see the need for an extension, because this is a normal and expected and reasonable state to be in that doesn't require special code.

This version just wraps around the same implicit operator, and gets optimized away eventually, meaning it's zero overhead.

Why do i need an extension method that literally serves just to remove a NRT warning that did not need to be tehre in the first place. The documented capability of ROS is that is can wrap a null array. It's expected to be able to do that. We want it to be able to do that. It's a good thing that it can do that. Needing to jump through hoops to make code work that is perfectly sensible and reasonable is just needless friction.

addresses a scenario which should not be encouraged

I know of nothing that makes me think there is anything about this scenario that should warn or otherwise impede the user.