On Saturday, 16 November 2013 at 23:34:55 UTC, Jonathan M Davis
wrote:
If you want to use the type system to try and protect against
dereferencing
null, then having wrapper which guarantees that the object
_isn't_ null makes
a lot more sense, particularly when just because you used
Optional<T> instead
of T mkaes no guarantees whatsoever that all of the other T's
in the program
are non-null. At best, if Optional<T> is used 100%
consistently, you know that
when a naked T is null, it's a bug.
You're right, it's better to ensure that the object is not null
in the first place, which is what languages like Haskell, Spec#,
Kotlin, and Rust do. D currently doesn't do this, and most
developers probably won't have the discipline to use NonNull
consistently throughout their code. The best we can do on that
front is make sure it's used consistently within Phobos, so we
can guarantee that we'll never give a user a null value.
Honestly, I pretty much never have problems with null
pointers/references, and
my natural reaction when I see people freaking out about them
is to think that
they don't know what they're doing or that they're just plain
paranoid. That
doesn't mean that my natural reaction is right.
I think in this case, your natural reaction is wrong, because
you've used mostly languages with nullable references. It's a
case of the blub fallacy: "Nullable references are good enough.
Why bother with all that hairy non-nullable stuff?"
It could easily be the case
that many such people are merely programming in environments
different enough
from anything I've had to deal with that null is actually a
real problem for
them and that it would be a real problem for me in the same
situation. But in
my experience, null really isn't a problem, and it can be very
useful. So, when people freak out about it and insist on trying
to get the type system to
protect them from it, it really baffles me. It feels like
they're trying to take
a very useful tool out of the toolbox just because they weren't
careful and
managed to scratch themselves with it once or twice.
I don't think anyone's freaking out about null, and you're right
that null is useful. The question is, why do we need object
references to be nullable by default? If they were non-nullable
by default, we could eliminate a whole class of errors for free.
Not for some arcane definition of free. This is a free lunch that
is being refused. You seem to be asking the question "why do we
need them", when you should be asking "what do we lose by not
having them".
Note that I'm arguing for non-nullable references here, which D
is obviously never going to have. The next best thing is, as you
suggested, having a wrapper type that we can use to be reasonably
sure never holds a null reference. Again, the problem with that
is that it requires programmer discipline.
And Java's Optional seems even more useless, because it doesn't
actually
protect you against dereferencing null, and because it doesn't
prevent
anything which isn't in an Optional from being null.
See, that's the problem. References are nullable by default in
Java, so even with an Optional type and a NonNullable wrapper you
can never be 100% that you're not dealing with null masquerading
as an object. The truly safe thing would be to enforce in the
language that all references are wrapped in Optional by the
compiler, or make a language change to disallow null references,
but doing either of those is not at all realistic. Still,
creating a convention of avoiding objects that aren't wrapped in
Optional among Java developers could get you pretty close.
Much as I don't think that it's worth it, I can at least see
arguments for
using NonNullable (which will end up in std.typecons
eventually) to guarantee
that the object isn't null, but I really don't think that using
Optional or
Nullable on a nullable type gains you anything except the
illusion of
protection.
Well, again, Optional would force you to check that the
underlying object was null before you used it. You simply can't
call, say, calculatePrice() on a Nullable!SalesGood (well, you
actually can due to the fact that Nullable aliases itself to the
wrapped object, which is a huge mistake IMO).
Oh, well. null seems to be a very divisive topic. There are
plenty of folks
who are convinced that it's a huge disaster, and plenty of
others who have no
problems with it at all and consider it to be useful. And for
some reason, it
seems like the folks in Java land freak out over it a lot more
than the folks
in C++ land, and aside from D, C++ is definitely the language
that I've used
the most and am most comfortable with, as well as tend to agree
with the
proponents of the most (though obviously, it has plenty of
flaws - hence why I
prefer D).
I think "huge disaster" might be a mischaracterization on your
part. There is no worldwide hysteria over nullable references,
just a growing realization that we've been doing it wrong for the
past 20 years. And yes, null is useful to indicate the absence of
a value, but objects don't have to be nullable by default for you
to use null. Many languages make the programmer ask for a
nullable reference specifically by appending ? to the type, which
makes everyone reading the code aware that the reference you have
might be null, and to take appropriate care.
