Proposing std.typecons : Optional (with PR)

[Johannes Loher]

Am 11.06.19 um 13:47 schrieb FeepingCreature:
> My impression is that the distinction turns on whether the null case can
> be expected to occur in "normal use" of the type. As `Nullable` says,
> accessing `get` while the `Nullable` `isNull` is *undefined*; that is,
> at the level of accessing missing array keys. (Except you can access
> them implicitly.) From this I infer that `Nullable` is mostly supposed
> to be non-null, maybe to enable delayed initialization or the like,
> which would justify the `alias get this` and match the unittests.
> 
> This is a *very* different thing from an `Optional` type! An `Optional`
> type is expected to be unset in normal operation. (That's why my
> implementation throws an Exception on access, not an Error.) That is,
> the user is expected to regularly encounter `Optional`s whose value is
> absent, and handle this state in his ordinary control flow. Hence no
> implicit alias, and no AssertError on access.

Exactly. This is why I'd expect a "real" Optional type to provide a lot
more utilities to actually work with it, such as pattern matching,
orElse, iterating, mapping, flatMapping, filtering, etc.