On Sunday, May 20, 2018 01:51:50 IntegratedDimensions via Digitalmars-d-
learn wrote:
> Simply require == null as is null and be done with it.
That would be flat out wrong for dynamic arrays, because then
auto result = arr == null
and
int[] nullArr;
auto result = arr == nullArr;
would have different semantics. The way that dynamic arrays are designed to
work even if they're null mucks with this considerably here.
> You can't police programmers minds and get them to program correctly.
That's true, but making things that are highly likely to be wrong illegal
prevents bugs. e.g.
while(cond);
is illegal in D precisely because it's error-prone. There are cases where
doing something like that would be perfectly correct. e.g.
while(++a != b);
but you can do the exact same thing with empty parens
while(++a != b) {}
and all of those bugs with accidentally closing a loop with a semicolon go
away, and you don't lose any expressiveness. The compiler just forces you to
write it in a way that's far less error-prone.
Making it illegal to compare the null literal with == also prevents bug, and
you don't lose any expressiveness doing it either. It's the same kind of
logic. Making error-prone constructs illegal when there's a simple
equivalent that isn't error-prone is good language design, because it
prevents bugs without actually restricting the programmer. It's when the
language starts disallowing things that aren't error-prone and/or don't have
simple equivalents that you start running into problems with the compiler
getting in your way and treating you like a kid. For simple stuff like this,
it ultimately saves you time and effort without getting in your way. At
most, you occasionally have to replace foo == null with foo is null or
foo.length != 0, and it potentially saves you hours of effort tracking down
a subtle bug.
- Jonathan M Davis
