Current sentiment on Nullable.get

[Jonathan M Davis]

On Friday, December 14, 2018 8:26:17 PM MST Rubn via Digitalmars-d wrote:
> As a side note you could also easily add a separate function that
> would do what you are suggesting:
>
> bool hasValue() const;
>
> which wouldn't check if the value is null (for naturally nullable
> types). Now, tell me, what would you name the function to check
> if the value is null, including for naturally nullable types if
> you wanted to add it to the current Nullable struct ? What would
> you name that function to make it obvious to a read at first
> glance that that is how it functions.

Changing the behavior of Nullable would silently break existing code. So,
regardless of whether Nullable's current behavior is desirable, simply
changing its behavior is completely unacceptable.

And if we were designing Nullable from scratch, trying to make the names
involved clearer in the process, then it would probably just be something
like Optional, with isEmpty or hasValue being the function use to check
whether it contained anything rather than isNull. Either way, as I keep
pointing out, for it to be possible to reliably use it in generic code, it
needs its current semantics, and having it treat nullable types differently
makes it pointless to use it outside of generic code. As such, having a
Nullable/Optional type which treats pointers differently just makes no
sense.

But if you want that, as I understand it, you can find at least one library
on code.dlang.org that has defined its own Optional type which works that
way.

- Jonathan M Davis