Current sentiment on Nullable.get

aliak something at something.com
Thu Dec 13 11:41:01 UTC 2018


On Tuesday, 11 December 2018 at 22:32:45 UTC, Jonathan M Davis 
wrote:
> 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.

This is not the point of optional types. They're just there to 
denote if a value exists or not. The fact that you can use D's 
Nullable to avoid allocating an int* is a happy proxy effect at 
best and only applies to a subset of types T can take on.

And now I've heard three reasons for the purpose of Nullable:

* It's an optional/maybe type
* It's to give value types pointer semantics
* And now, it's to avoid heap allocations for value types

AFAIK, Nullable was modeled after C#'s Nullable. Which only 
applies to value types - and that makes sense. But the way it's 
used in D is just a pothole of confusion and WTFs (see below).

> 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.

That makes a big difference. With everything. Writing the code, 
maintaining code, reviewing code, coming back to code, getting in 
to a language. Principle of least surprises. Intuitiveness. These 
all matter:

class C {}
struct S {}

* What is Nullable!(int*)? An int * that can be null? But wait...
* What is Nullable!C? A reference type that can be null? Isn't 
that just "C" ? What is this adding? How does this make sense?
* What does this do: "Nullable!C a = null; a.isNull;"? if it's 
false does that mean C exists? So C exists?
* What is Nullable!S? A struct that can be null or a struct that 
may exist? Or was it just to avoid heap allocation?
* What's the difference between null and any of those other 
types' isNull?
* Nullable!C a = null; a.get; // should that throw/assert?

These are all non-obvious.

>
> 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.

It can be subjective, but there are also objectively better names 
and better APIs. And IMO we shouldn't settle for "fine" if we 
don't have to. Right now, I can accurately say this about 
Nullable:

Nullable is a type that can be null, but may not be null even if 
assigned null.

Is it subjective that that's good or bad? I personally think it's 
objectively bad.

>
> 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).

Yes, and this is just bad. Bad bad bad. How can any API that 
causes subtle bugs be something anyone would want to keep around??

Cheers,
- Ali





More information about the Digitalmars-d mailing list