An optional/maybe type with range semantics

[Dukc]

On Sunday, 25 February 2018 at 18:03:35 UTC, aliak wrote:
> Alo,
>
> Just finished up a first take on an optional type for D. It's 
> essentially a mix of Nullable and std.range.only, but with a 
> lot more bells and whistles. I would love to hear any feedback 
> on code, or features, or bad design or potential for better 
> designs from anyone who's interested :)
>
> Code: https://github.com/aliak00/optional
> Dub: https://code.dlang.org/packages/optional
> Docs: https://aliak00.github.io/optional/
>
> Things to do:
> * Handle dispatching of static fields/method (see code below)
> * Implement flatmap/decide if flatmap should be in here
> * Figure out what kind of range this should be (currently its 
> just an input range - should it be more?)
> * Implement some phobos algorithms as returning optionals (e.g. 
> countUntil)
>
> Anyway, here's some code to peak at a few of the supported 
> features:
>
> auto a = some(3);
> auto b = a + 4; // opUnary/Binary/Equals (so far) supported
>
> a = none;
> a++ // noop
>
> auto p = no!(int*);
> assert(a == *p) // none == none
> p = null;
> assert(a == *p) // null handled
>
> struct A {
>   struct B { void g() {} }
>   B f() { return B(); }
> }
>
> auto  b = no!(A*);
> b.dispatch.f.g // dispatch is safe, noop
>
> b = new A;
> b.dispatch.f.g // makes calls now because non empty.
>
> Cheers,
> - Ali

Honestly, I fail to see the idea behind this... Ranges do not 
need any nullability on top of them IMO, because an empty range 
can already be used to denote a kind of "default", "unassigned" 
or "nothing" - type of value.

On the other hand I may just be missing something... do you have 
an example use case for this where phobos ranges would be a bad 
option?

Anyway, good effort.