Current sentiment on Nullable.get

[Jonathan M Davis]

On Tuesday, December 11, 2018 2:48:36 PM MST aliak via Digitalmars-d wrote:
> On Tuesday, 11 December 2018 at 18:04:37 UTC, H. S. Teoh wrote:
> > On Tue, Dec 11, 2018 at 08:44:03AM +0000, aliak via
> >
> > Digitalmars-d wrote:
> >> On Monday, 10 December 2018 at 17:07:10 UTC, jmh530 wrote:
> >> > On Monday, 10 December 2018 at 15:47:53 UTC, aliak wrote:
> >> > > [...]
> >> >
> >> > 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?
> >>
> >> I would be all for that. I guess the only reason would be to
> >> have
> >> pointer semantics for value types 🤷‍♂️And I'm not really sure why
> >> you'd want that anyway.
> >
> > It's useful for representing a value that isn't there.  E.g.,
> > if I have a struct with some int fields parsed from some config
> > file, say, I'd like to be able to distinguish between a field
> > that's actually set, vs. one that isn't specified in the config
> > file.
> >
> >
> > T
>
> True! Sorry, I meant that as a response to "why would i use
> Nullable over the mentioned Optional library". In that case
> optional represents existence, and then the only thing nullable
> has over that is pointer semantics. But I think pointer semantics
> is a poor representation of the existence of a value. What's the
> difference between using Nullable!int and int* to see if it's set
> in terms of intent/semantics/safety? (I realize allocation would
> be a difference).

Ultimately, allocation is the main difference here. Nullable provides a way
to emulate the behavior of a pointer with regards to nullability without
having to allocate on the heap. An Optional or Maybe type is ultimately the
same thing, just with a different name. If it weren't for the issue of heap
allocation, it could easily argued that pointers negate the need for any
kind of Nullable/Optional/Maybe type, because they provide that
functionality. And they don't even cause memory safety issues if you're not
doing pointer arithmetic. So, really, I think that the need for heap
allocation is _exactly_ the issue here that these types are designed to
solve and that without that, a Nullable/Optional/Maybe type isn't adding
much. At most, it's making it clear that it's expected that the value can be
null/empty/missing, because not all functions that involve pointers consider
null to be an acceptable value.

And IMHO, the arguments about Nullable vs Optional vs Maybe etc. are mostly
nonsense in that it's really just an argument about how the type is named.
And while names matter, any of those names work just fine, and it's
ultimately very subjective. It's like arguing about whether strip or trim is
a better function name for a function that removes whitespace from the end
of strings. Either name works just fine. The difference is pretty much just
a difference in preference or expectation based on what the programmer has
seen other languages or libraries do. It's entirely subjective.

IMHO, the only real naming issue that we have with Nullable is that once it
was changed to allow actual pointers (whereas originally, it just contained
types that could not themselves be null), the property isNull became
confusing to some folks, because they thought that the null value of a
pointer and whether the Nullable itself was null were related, when they're
not (and if they were, it would cause subtle bugs - especially in generic
code). So, based on that, it could be argued that Nullable is a worse name,
but originally, since it didn't even allow types that were themselves
nullable, that was a non-issue, and at this point, we don't change the names
of things in Phobos just because we decide that another name is better,
because Walter and Andrei don't think that that's worth the code breakage.
To change or replace Nullable, we'd need a reason other than some folks
wanting a different name in order to change it. The alias issue is arguably
worth a deprecation given how code that uses a Nullable really should be
written with the idea that it could be null rather than having an actual
value, and having the alias makes it easier to introduce bugs related to
that, but that doesn't require replacing Nullable or changing how it
fundamentally works. It just means deprecating the alias. Nullable itself
can continue to function the same way, and plenty of code using Nullable
would not need to be changed due to deprecating the alias.

If someone prefers some other implementation of what Nullable is doing,
they're free to use that instead, but most of the arguments around replacing
Nullable seem to either revolve around the fact that some folks don't like
the name or the fact that they think that a Nullable containing a type that
can be null should use whether the value is null to determine whether the
Nullable is null/empty instead of using a separate bool, and IMHO, doing so
would just be a source of bugs. Also, at least some existing code relies on
that functionality (e.g. it's been mentioned before that vibe.d relies on
it).

- Jonathan M Davis