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

[Adnan]

On Friday, 14 February 2020 at 14:43:22 UTC, Petar Kirov 
[ZombineDev] wrote:
> On Friday, 14 February 2020 at 08:54:41 UTC, Adnan wrote:
> 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.

Very interesting. I always thought that Option<T> is a type-guard 
for enforced null checks (I could be wrong here). But seems to me 
that this design circles back to square 1: having the callee 
remember to check if the length of the range is 0 or 1. Which is 
essentially similar to check sentinel values (i.e. check if the 
binarysearch returns -1 as index). What languages do this?

What does Aliak's package provide that's fundamentally different 
to just returning a T[]? Empty T[] would mean `None` and a T[] 
with 1 item means `Some(T)`?

> 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
Nim's optional works this way too:

import options

let v = none(int)
echo v + 4 # error

Scala:

val a: Option[Int] = None
println(a + 4) // compile error

Even C++:

#include <iostream>
#include <optional>

auto main() -> int {
    std::optional<int> a;
    std::cout << a + 4 << std::endl; // compile error
}

>(although limited to just
> pointers for now) is work in progress:
> https://github.com/dlang/dmd/blob/master/changelog/ob.md

Nice, any chance it's going to work with non-ptrs too?