What is the rationale behind enabling Nullable!T to be used as a regular T?

[Petar]

On Friday, 14 February 2020 at 08:54:41 UTC, Adnan wrote:
> Nullable!T, as I understand is somewhat similar to Rust's 
> Option<T>. It's meant to be an alternative to sentinel value 
> based error checking.
>
> In regular Rust code if you do something like
>
> let x: Option<i32> = None;
> println!("{}", x + 4);
>
> It should throw compile error, since the `x` in `x + 4` is not 
> checked for null. OpAdd<rhs = i32> is not implemented for 
> Option<i32> for that reason.

The two ends of the design spectrum (as I see it) are:
1. `Optional(T) x` as a range of [0,1] elements of type `T`. For 
all possible operations `op` on type `T` there exists an 
operation `Option(T).op` and the effect of executing is 
equivalent to `x.map!fun`. This is what aliak's optional package 
provides.

2. `Optional(T) x` behaves like a null-able pointer. The compiler 
statically prevents dereferencing if it can't prove that x is 
non-null. Such as scheme (although limited to just pointers for 
now) is work in progress:
https://github.com/dlang/dmd/blob/master/changelog/ob.md