Overload operator nullable ?

[Thaina]

Revise from #494 to allow nullable operator ?. and ?? for any struct

struct Fraction
{
    public long Number,Divider;
    public double Value { get => Number / (float)Divider; }

    // return boolean if null
    public static bool operator?(Fraction value) => Number == 0 && Divider == 0;
}

Fraction frac;

double? d = frac?.Value * 5;

if(frac == null) // override ? also enable == for struct on null
   frac = 0; 

[DavidArno]

With a bit of tweaking, this idea could lead us to a very good place: a maybe type that already exists within folk's code.

Many people use nullable as a maybe construct: null is no value; not null is a value. Extending this such that, if it needs to, a struct can declare itself null takes us a step closer to having null being able to use nullable as a maybe.

However, we still have the dreaded NullReferenceException (NRE) hovering in the background, ready to catch us out. Nullable type flow analysis will take us one more step toward safely using nullable as a maybe.

The final step could be achieved through having a bottom type, which has the single "value": null. Then because null automatically has a type, that type can implement some members. The essential one would be the HasValue property. But it could also implement eg the ToString() method.

This would then mean that code like the following becomes possible:

T? TryFoo<T>() => ...

var x = TryFoo<SomeClass>(); // x is SomeClass?
if (x.HasValue) // HasValue is implemented by bottom type. null.HasValue avoids NRE
{
    // x is not null here; flow analysis understands this and can treat x as SomeClass
}
else
{
    var y = x.ToString(); // ToString implemented by bottom. null.ToString() returns "null"
    var z = x.Bar(); // compiler warning as x is null
}

[CyrusNajmabadi]

Why woudl you need this? Fraction is already a struct, and so can't be null. If you want to support the null value, you can. with Fraction?. If you want to support a domain specific sentinel, you can, with any sort of appropriately named property of your choice. I recommend IsNaLF (IsNotALegalFraction).

Appropriately this would have no relation to null/nullable/etc. because your helpful sentinel value is not null. It's a real value, just one (of potentially many) that you don't consider valid in your domain (but which are totally valid in the entire .net domain).

Also... if you really want to compare your type to null (like you have in your code), why not just add:

        public static bool operator==(Fraction f, Fraction? f2) { return true; }

?

With that, you can write if(frac == null) and it will call into your overloaded operator.

You can also overload operator true/false if you want this value to behave in the realm of things that can be truthy tested. It's not clear to me why we'd need more ways to make user types have special behavior.

[DavidArno]

@CyrusNajmabadi,

Why woudl you need this?

Because it provides a solution to coping with default structs that have an invalid/meaningless value, such as Fraction. Flow analysis could be used with structs that declare a public static bool operator ?:

Fraction f = default; // compiler warning: assigning a possible null to a Fraction variable

If we took this a step further and eg decorated the operator with information on when it'll be null:

[NullOnDefault]
public static bool operator?(Fraction value) => Number == 0 && Divider == 0;

Then that compiler warning can be definite over the null state, rather than warning on a "possible null".

[Thaina]

@CyrusNajmabadi It just that IsNotALegalValue can be treat the same way as null to use in the long chain of nullable type

Fraction is just easy example that some kind of data can be null-like state

var text = someClass?.NullableStruct?.ToString();

Not only that, one thing I want is custom nullable type. Because we have Nullable<T> being a default for nullable struct, it can access its value only from property, which need to be copied to see value. If we have custom nullable then we would be able to access its field directly but still able to use nullable operator in other places

[CyrusNajmabadi]

Because it provides a solution to coping with default structs that have an invalid/meaningless value, such as Fraction.

There are already existing solutions for copying with that :) For example, ImmutableArray has "IsDefault".

I also showed how you can provide your own custom equality if you want your "invalid" values to somehow have a relation to "null" values.

It's unclear why a new language feature is needed here.

[CyrusNajmabadi]

If we have custom nullable

Why can't you make your own custom nullable? And just define appropriate operators on it (like operator==)?

[Thaina]

@CyrusNajmabadi I don't add new feature here. I just want to make alike pattern can reuse same operator for the same intention

In my opinion null is the invalid value for class. And nullable operator just test for invalidness. I want the same operator to do the validation code so it not scatter around like IsValid IsDefault IsInvalid IsNotLegal etc/etc/etc instead we test it with just null and ?. and ?? and also other in the future

[CyrusNajmabadi]

In my opinion null is the invalid value for class.

I disagree. Note, for example, that you cannot use ?. on a reference type to test it for other potential 'invalid values' that you might see in your domain.

I want the same operator to do the validation code so it not scatter around like IsValid IsDefault IsInvalid IsNotLegal

I would personally not like that. Because now i have to know that these operators now have potentially special meaning for your particular domain. That means, for example, that i might know that a value was non-null, but then i'd see a ?. which i would then think was inappropriate. However, removing the ?. would change code meaning as you were not just testing for null, but also your special 'invalid' values in your particular domain.

[CyrusNajmabadi]

Note: having actual named accessors here seems far better as it actually conveys how the values are special and why you might need to care. Consider how this is handled for floating point values. There are values like infinities, and nans, and whatnot. Because of how they all may need to be specially handled, it's important to be able to tell which is which, and not just have them all bucketed together. Nice names make it clear what's happening.

The same holds for something like ImmutableArray. It has a 'default' state (as it's a struct) which you can check for with .IsDefault. But you can also check .IsEmpty as well as having hte convenience '.IsDefaultOrEmpty'. These names make it clear what is being tested and what the state of the value is if the test is true or not. Rolling these up into generic operators makes the code less clear as now i have to know how you applied that operator to your domain. Today, i know exactly what the operators mean across all domains, and i can reason about them as such. Removing that understanding seems like a bitter pill to swallow.

[DavidArno]

I disagree. Note, for example, that you cannot use ?. on a reference type to test it for other potential 'invalid values' that you might see in your domain.

With this proposal, you could. eg,

class Foo
{
    bool _valid;

    ...

    public static bool operator ?(Foo value) => value is null || !_valid;
}

var x = new Foo(); // Foo is invalid by default
var y = x?.Bar(); // Bar isn't called and y is null as ? operator returns false

[Thaina]

@CyrusNajmabadi It's understandable that you would disagree but please understand that this feature was created on this thought

you cannot use ?. on a reference type to test it for other potential 'invalid values' that you might see in your domain

When I write this issue I'm also not sure that should we allow class to override this pattern too or not. But there are an example in unity3D GameObject class that it could be compared to null to check that was it already destroyed. Yet if you call gameObject?.ToString() it still return valid string, not null as expected

So if we let struct can override this, maybe class should be able to too

that i might know that a value was non-null, but then i'd see a ?.

I think opposite to that. If any struct can use ?. without error then it means it intentionally explicitly be written to have invalid value, which could be expressed as null. And struct like that will intentionally tell you that it should not be used while it invalid

[Thaina]

@CyrusNajmabadi For me float.Infinite is not invalid. Only float.NaN is invalid

[CyrusNajmabadi]

Sure. For you :) That's why it's domain specific. The point is that names allow it to be very clear what's actually going on, and to allow the consumer to decide what's going on and how they would want to make sense of it.

[sharwell]

This sounds like another case which #727 could resolve. It wouldn't look exactly the same way in code, but it could accomplish the same underlying goals (preventing the use of invalid/uninitialized values).

[wilhelmzapiain]

I really like this proposal and I would like the operator to also apply to classes that act like wrappers (which is how it is applied today). A Maybe{T} or WeakReference{T} should return a {T} in the '?' operator when valid (just like Nullable{T}).

The signature could be like this:

class Foo
{
    public static bool operator ?(Foo value, out Bar result) ...
    ...
}

Changing Bar to Foo allows for self-validating classes.

For example a Maybe class would be:

class Maybe<T>
{
    public static bool operator ?(Maybe<T> value, out T result)
    {
        var valid = !(value is null) && value.HasValue;
        result = valid ? value.Value : default;
        return valid;
    }
    Maybe() ...
    bool HasValue ...
    T Value ...
}

And used like this:

class Bar
{
    void DoSomething() ...
}

var x = new Maybe<Bar>();
...
x?.DoSomething();

Theres is drawback in that the operator loses the guarateed thread-safe calling when overriding the behavior, leaving to the implementer the burden of ensuring thread-safety.

[wilhelmzapiain]

@CyrusNajmabadi I agree that there is always high risk when overloading operators. They should be carefully documented and do what the user would expect. Applying it to double would be a mistake, because it is as domain-agnostic as it comes.

But the pattern of checking if a value or class is valid before calling (more-so when an exception is the alternative) is frequent enough that I believe it warrants the expansion of the operator semantics to shorten the code written; just as the pattern of checking nullability warranted the creation of the operator in the first place.