Is there a strong reason for Nullable's alias get this?

[SimonN]

On Monday, 16 April 2018 at 10:10:56 UTC, FeepingCreature wrote:
> Nullable!T to T is a narrowing conversion, since T cannot 
> express the null case. Therefor, it must not be implicit.

I agree with this. To even reach for a Nullable type in one's 
codebase incurs a cost -- the need is substantial to oughtweigh 
this complexity. In this situation, one will design internal 
interfaces both with and without Nullable. The strict typechecks 
(prevent assignment of Nullable!A to A) make large codebases of 
this kind safe to refactor.

If the checks must get more verbose because Nullable isn't part 
of the language, but rather a library feature, that's certainly a 
cost to pay for reliability. But it's still better than these 
runtime crashes. It's sad every time code crashes at runtime with 
errors that other type systems easily find at compiletime.

An alternative to Phobos's Nullable might be aliak's Optional? 
It's in the dub registry as "optional", or on github: 
https://github.com/aliak00/optional

     import optional;
     struct S { int i; }
     void main()
     {
         Optional!S s = some(S(5));
         S t = s;
     }

This produces the desired error at compiletime: 
source/app.d(6,11): Error: cannot implicitly convert expression s 
of type Optional!(S) to S.

-- Simon