is ==

[Jonathan M Davis]

On Saturday, May 19, 2018 01:27:59 Neia Neutuladh via Digitalmars-d-learn 
wrote:
> On Friday, 18 May 2018 at 23:53:12 UTC, IntegratedDimensions
>
> wrote:
> > Why does D complain when using == to compare with null? Is
> > there really any technical reason? if one just defines == null
> > to is null then there should be no problem. It seems like a
> > pedantic move by who ever implemented it and I'm hoping there
> > is actually a good technical reason for it.
>
> tldr: this error is outdated.
>
> In the days of yore, "obj == null" would call
> "obj.opEquals(null)". Attempting to call a virtual method on a
> null object is a quick path to a segmentation fault. So "obj ==
> null" would either yield false or crash your program.
>
> Except it's worse than that; your opEquals method had to
> explicitly check for null. So if your class had a custom equality
> function, "obj == null" was probably going to segfault no matter
> what.
>
> Because of this common source of errors, in DMD 2.012 (2008), we
> got an error only for the case of comparing with a literal null.
> (The compiler isn't a mind-reader; it doesn't know whether that
> variable will be null when that line of code executes.)
>
> This still sucked, so in 2015 we got a runtime function to handle
> object equality:
> https://github.com/dlang/druntime/blob/dff824eda422b1fcdde5f2fe53120fcd717
> 33aaa/src/object.d#L140
>
> But we haven't removed the error message.

Actually, that runtime function has existed since before TDPL came out in
2010. It even shows the implementation of the free function opEquals (which
at the time was in object_.d rather than object.d). I'm not even sure that
the error message was added before the free function version of opEquals
was. Maybe when that error message was first introduced, it avoided a
segfault, but if so, it has been a _long_ time since that was the case.

> It *is* faster to call "foo is null" than "foo == null", but I
> don't think that's particularly worth a compiler error. The
> compiler could just convert it to "is null" automatically in that
> case.
>
> One casualty of the current state of affairs is that no object
> may compare equal to null.

Honestly, while the compiler probably should just convert obj == null to obj
is null, there really still isn't really a good reason to ever use == with
null. It's _never_ better than using is, and in some cases, it's worse. Of
course, the most notable case where using == with null is a terrible idea is
dynamic arrays, and that's the case where the compiler _doesn't_ complain.
Using == with null and arrays is always unclear about the programmer's
intent and almost certainly wasn't what the programmer intended. If the
programmer cares about null, they should use is. If they care about lengnth,
then that's what they should check. Checking null with == is just a huge
code smell.

So, perhaps the compiler is being pedantic, but it's still telling you the
right thing. It's just insisting about it in the case where it matters less
while not complaining aobut it in the case where it really matters, which is
dumb. So IMHO, if anything, adding an error message for the array case would
make more sense than getting rid of the error with pointers and references.

- Jonathan M Davis