Proposing std.typecons : Optional (with PR)

[FeepingCreature]

On Tuesday, 11 June 2019 at 11:02:34 UTC, Marco de Wild wrote:
> I agree that Nullable has behaviour that is unwanted. However, 
> does this really warrant a new type in the standard library 
> that contains the same functionality but with different 
> implementation details? From the perspective of someone who is 
> not too familiar with the standard library, which one do they 
> need to choose? Why would they pick Optional over Nullable? Why 
> would they pick Nullable over Optional? If Optional coexists 
> with Nullable, IMO it needs to have a distinct use case to 
> prevent confusion.
>
> I would prefer to fix Nullable and have one consistent way of 
> dealing with this problem in the standard library, rather than 
> a (so it seems) "battle" between Nullable and Optional fighting 
> for attention and usage. I don't know if any Phobos' functions 
> use Nullable, but those would need to be updated to work with 
> Optional as well (for said consistency).
>
> I didn't comment earlier, but I am in favour of your earlier 
> pull request.

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.

I too, would prefer to get `Nullable` into a state where it can 
serve as an Optional type. However, given the amount of forum 
interest in this has been an approximate **zero**, I've chosen to 
take any and every avenue that may at some point lead to a sane 
Optional type in the standard library. I am **sick** of spending 
hours debugging `alias get this` issues, or being told that a 
coworker spent hours debugging an `alias get this` issue. 
Whatever gets me rid of them, I will do. I don't care which of 
these PRs gets attention. The `Optional` PR does not obsolete the 
`deprecate alias get this` PR. If either of them gets traction, I 
will be glad of it.