Current sentiment on Nullable.get

[H. S. Teoh]

On Mon, Dec 10, 2018 at 05:07:10PM +0000, jmh530 via Digitalmars-d wrote:
> On Monday, 10 December 2018 at 15:47:53 UTC, aliak wrote:
> > [snip]
> > 
> > Sounds like a step forward, deprecating that.
> > 
> > Do people consider Nullable a type of Optional thing in general? I
> > have a written a bit more details here [0] but basically I don't
> > think deprecating .get is enough to make it "safe" - granted -
> > depending on what safe means. In the context of D a segfault is safe
> > so maybe that's ok. But then deprecating get doesn't add safety in
> > that context anyway.  And, I've never really considered Nullable as
> > something that provides Optional semantics. But maybe that was it's
> > intention?
> > 
> > [0] https://github.com/aliak00/optional/blob/03e0dc0594f1f19274389227e67dd3fba00a9d3f/README.md#what-about-stdtypeconsnullable-and-stdrangeonly
> 
> Does it make sense to deprecate Nullable as a whole, rather than just
> that piece? Why would I use Nullable when I can use your optional
> library?

AFAIK, Nullable was intended for giving an extra "null" value to
by-value POD types.  Outside of that narrow use case, it's really not a
very nice API at all, and the implementation is a bit simplistic, dating
from an earlier time when we didn't have as many attributes / new
features as we do today. As a result, there are some very nasty corner
cases where it behaves in counterintuitive ways that can't be fixed
without breaking existing code in evil ways. Its name is also a bit
misleading, esp. when you apply it to by-reference types.

There have been various attempts to give it a facelift, but so far none
has made it through.  I'm inclined to agree with deprecating it, except
I dread the long painful process of getting a replacement added to
Phobos.


T

-- 
Freedom: (n.) Man's self-given right to be enslaved by his own depravity.