Proposing std.typecons : Optional (with PR)

[Marco de Wild]

On Tuesday, 11 June 2019 at 07:46:38 UTC, FeepingCreature wrote:
> Since my rfc regarding deprecating `alias get this` in Nullable 
> (see https://github.com/dlang/phobos/pull/7060 ) encountered no 
> meaningful criticism (as I'm tactfully choosing to interpret 
> the total absence of reaction), but somebody mentioned that a 
> new type may have more success, since it doesn't have to 
> justify itself in the same way as a change to existing 
> behavior, I present `Optional`: 
> https://github.com/dlang/phobos/pull/7065 .
>
> To reiterate the difference:
>
> `Nullable` is the standard type for "adding an undefined value 
> state to an existing type". It's being abused as an `Optional` 
> type. Why "abused"? Well:
>
> 1. `get` is **undefined** if Nullable is null
>
> 2. `get` is called implicitly.
>
> This is not good behavior for an `Optional` type! Since my 
> attempt to turn `Nullable` into an `Optional` type encountered 
> zero enthusiasm and mild resistance, I've started a second 
> parallel attempt to introduce an `Optional` type from scratch.
>
> (Translation: I've copypasted `Nullable` and changed a few 
> names.)
>
> Opinion? Anyone? Anyone at all? I'm so alone...

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.