Optional and orElse: design feedback/critique?

[Alexandru Ermicioi]

On Saturday, 27 July 2019 at 13:17:32 UTC, aliak wrote:
> PS: I realize an obvious first comment is "what about 
> Nullable!T". A number of reasons: 1) it doesn't have a range 
> interface 2) the reference semantics are not desirable for me 
> and writing generic code is awkward 
> (https://github.com/aliak00/optional#what-about-stdtypeconsnullable), 3) alias this, although deprecated, breaks it completely, 4) maintaining a dub package feels much more productive.Skimmed a bit through main optional module, and have some questions/suggestions.

Just wondering whats the reason of treating not null as being a 
value? Per my knowledge the meaning of null basically translates 
to "no value", does it not make sense to have null be treated as 
empty optional, and consequently any null pointer?


Saw you're using from pattern to import symbols, wouldn't it make 
a template bloat and increase compile time given big projects?

As for aliasing what is the problem with it? Would not it be 
better than introspecting and defining operator overloads in 
Optional? Existing design would introduce overhead on compilation 
time due to introspection of payload.

I see you can assign value to optional payload wouldn't it be 
better to have Optional contents pseudo immutable, and have any 
changes defined through copies of it?

Regarding toString, a sink version would be nice to have as it 
allows nogc use of it.

Json conversion could be outside of Optional in a separate module 
or even project, since some people might want serialization not 
only to vibe d.

If we'll treat null values as empty then won't be any need in 
none type, and optional == null would be enough.

`some` for constructor of nullable is too generic name, maybe 
rename it to optional/asOptional, it will make more sense and be 
consistent with toOptional present in project.

toNullable could be moved as opCast maybe.

Best regards,
Alexandru.