Ary Borenszweig wrote:
Jeremie Pelletier wrote:
Ary Borenszweig wrote:
Walter Bright wrote:
Daniel Keep wrote:
"But the user will just assign to something useless to get around
that!"
You mean like how everyone wraps every call in try{...}catch(Exception
e){} to shut the damn exceptions up?
They do just that in Java because of the checked-exceptions thing. I
have a reference to Bruce Eckel's essay on it somewhere in this
thread. The observation in the article was it wasn't just moron
idiot programmers doing this. It was the guru programmers doing it,
all the while knowing it was the wrong thing to do. The end result
was the feature actively created the very problems it was designed
to prevent.
Or uses pointer arithmetic and
casts to get at those pesky private members?
That's entirely different, because privacy is selected by the
programmer, not the language. I don't have any issue with a
user-defined type that is non-nullable (Andrei has designed a type
constructor for that).
If someone is actively trying to break the type system, it's their
goddamn fault! Honestly, I don't care about the hacks they employ to
defeat the system because they're going to go around blindly shooting
themselves in the foot no matter what they do.
True, but it's still not a good idea to design a language feature
that winds up, in reality, encouraging bad programming practice. It
encourages bad practice in a way that is really, really hard to
detect in a code review.
I like programming mistakes to be obvious, not subtle. There's
nothing subtle about a null pointer exception. There's plenty subtle
about the wrong default value.
And what about the people who AREN'T complete idiots, who maybe
sometimes just accidentally trip and would quite welcome a safety rail
there?
Null pointer seg faults *are* a safety rail. They keep an errant
program from causing further damage.
Null pointer seg faults *not being able to happen* are much more
safe. :)
There is no such thing as "not being able to happen" :)
Object thisCannotPossiblyBeNullInAnyWayWhatsoever = cast(Object)null;
Object is not-nullable, Object? (or whatever syntax you like) is
nullable. So that line is a compile-time error: you can't cast a null to
an Object (because Object *can't* be null).
You might be the only one here that understands Walter's point. But
Walter is wrong. ;-)
union A {
Object foo;
Object? bar;
}
Give me a type system, and I will find backdoors :)
I didn't say Walter was right or wrong, I said I understand his point of
view. The sweet spot most likely lie in the middle of both arguments
seen in this thread, and that's not an easy one to pinpoint!
I think we should much rather enforce variable initialization in D than
nullable/non-nullable types. The error after all is that an unitialized
reference triggers a segfault.
What if using 'Object obj;' raises a warning "unitialized variable" and
makes everyone wanting non-null references happy, and 'Object obj =
null;' raises no warning and makes everyone wanting to keep the current
system (all two of us!) happy.
I believe it's a fair compromise.
