Proposal: Drop OptionUnsafe and EitherUnsafe

[louthy]

If you go back to the original README for language-ext from nearly 10 years ago. You'll see its original reason to exist was:

• Poor tuple support
• Null reference problem
• Lack of lambda and expression inference
• Void isn't a real type
• List processing

We now have first-class tuple support, nullable references, better lambda inference, and new list syntax [1, 2, 3]. The one thing we don't have (officially) is a Unit type, but I guess we can't win them all.

Obviously, language-ext is much more than a resolution of these issues, but I think it's interesting to see how far we've come in that time.

Originally language-ext was setup to not allow null in any of the core types. With exceptions for OptionUnsafe and EitherUnsafe - that were named Unsafe as a nod to the risk of using null.

I am doing my best to migrate all of language-ext to have nullable annotations (it's a massive effort!). Though one thing that strikes me now is that maybe we don't need OptionUnsafe and EitherUnsafe any more. With nullable annotations we could have Option<A?> and then let the compiler warn the user, rather than completely blocking null from the 'container' types.

Full Proposal

• Provide nullable annotations for the whole library (this is happening anyway)
• Deprecate OptionUnsafe and EitherUnsafe with the [Obsolete] attribute
• Let all other types (Option, Either, Seq, etc.) use nullable references

The only downside I can see is for those that don't have <Nullable>enable</Nullable> in their projects. They'll lose the protective benefits of the null-rejecting types. The upside is that every language-ext 'container' type can be opted into using null references (and it's declarative).

[harrhp]

1. I don't think Option<A?> should be possible at all. Does it mean Some(null) is possible? The only places where nullable annotation makes sense to me are Case property and ToValueUnsafe extension
2. Deprecation of *Unsafe makes sense. But i think driving people to use Option is better than allowing null everywhere

[louthy]

1. I don't think Option<A?> should be possible at all. Does it mean Some(null) is possible? The only places where nullable annotation makes sense to me are Case property and ToValueUnsafe extension

OptionUnsafe exists, it is already possible to do SomeUnsafe(null). There are absolutely use-cases for that, hence its existence. However, now that we have nullable-references, we have a declarative way of demonstrating that null is an accepted value - previously we didn't have that option. So, without the protections of Option you'd have no idea whether there was a null inside or not. Now we do, because Option<A?> is not the same as Option<A> to the compiler. The first would allow nulls, the second wouldn't.

The declarative aspect of this means that null isn't the danger it once was.

[StefanBertels]

My 2 cents: Dropping *Unsafe variants is fine. I personally use T? if I need to handle null values.

But what about Option<string> o = null; and what about Prelude.Optional?
Currently null will be converted to None.

What about

Option<string?> o1 = null;
Option<string> o2 = o1;

Option<string> o3 = null;
Option<string?> o4 = o3;

I get Warning CS8619 Nullability of reference types in value of type 'Option<string?>' doesn't match target type 'Option<string>' but what should be the state (Some/None)? Currently everything looks fine and in standard code we have just two cases (None or Some with non-null reference).

[louthy]

The implicit conversion will work the same way as it does now. One major reason is it's not possible to know at runtime (efficiently) whether the Option type is A? and so maintaining the existing behaviour makes sense here. It's also not allowed to do this:

public static implicit operator Option<A>(A a) =>
    Some(a);

public static implicit operator Option<A>(A? a) =>
    Optional(a);

public static implicit operator Option<A?>(A a) =>
    Some(a);

public static implicit operator Option<A?>(A? a) =>
    Some(a);

So, its behaviour will remain as:

public static implicit operator Option<A>(A? a) =>
    Optional(a);

And, Optional will continue to switch on null - as it's what it's for and has been used as such forever - so its behaviour will remain as-is:

public static Option<A> Optional<A>(A? value) =>
    value is null
        ? default
        : new Option<A>(value);

For this example:

Option<string?> o1 = null;
Option<string> o2 = o1;

Obviously, this creates a compiler warning, but if you ignore it...

• o1 will be None. If you want it to be null you must use Some(null) or Pure(null).
• o2 will be None. None will always be None and so any conversion between the two would maintain that.

Option<string> o3 = null;
Option<string?> o4 = o3;

This also creates a compiler warning, but if you ignore it...

• o3 will be None
• o4 will be None.

If you want to create an Option<A?> in a Some state and with a value of null you must call Some<A?>(null).

So, really, if you've never used OptionUnsafe before then there will be no change for you. If you have, then you will need to make sure any implicit conversions from null are wrapped with Some(null). I figure that OptionUnsafe (and EitherUnsafe) has minimal usage and so this will be low impact for most users.

I've actually already implemented this proposal as part of the v5 refactor. Mainly because the next release is going to have some big migration implications - and so I want to gather everything together to make the pain a once-only event. I'm going to write a code-migrator to reduce the pain as much as I can. But still, I'm always interested in potential gotchas anyone can think of.

[harrhp]

The only concern i have is that even with nrt enabled null can still leak in runtime from api/db/non-nrt code. AppSwitch is something to consider to preserve null check in Option.Some and make it opt-in/opt-out