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.

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.

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