is ==

[Jonathan M Davis]

On Friday, May 18, 2018 23:53:12 IntegratedDimensions via Digitalmars-d-
learn 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.

Because == is pretty much never what you want to do with null. How much it
matters depends on the types involved, but if you really want to check for
null, is is definitely the right thing to use.

In the case of pointers and references, is checks that they're pointing to
the same thing. So,

foo is null

directly checks whether the reference or pointer is null. On the other hand,
if you use ==, it's calling some form of opEquals. For pointers, that should
generate identical code, but for class references, it means calling the free
function opEquals. That function will check whether the references are null
before calling opEquals on either of the class objects, but it does add
unnecessary overhead (which, as I understand it, the compiler is
unfortunately not currently able to optimize away) and provides no benefit
over checking with is.

Now, where is vs == _really_ matters (but unfortunately, the compiler does
not complain about) is with dynamic arrays. If you do

arr is null

then the compiler will check whether the array's ptr is null. So, something
like

"" is null

would be false. However, if you use ==, then it compares the length of the
array and then only compares the ptrs if the length is non-zero. So,

"" == null

is true. So, with dynamic arrays, using == with null is a huge code smell.
It _may_ be exactly what the programmer intends, but the odds are pretty
high that they just don't properly understand the difference between is and
==, and they meant to be checking whether the array was actually null but
just ended up checking whether its length was zero (which won't matter for
some code but will cause subtle bugs in any code that treats null as special
- e.g. if that is used to indicate that the array had not been given a
value). Now, because of how == treats null like empty, it _is_ a bit risky
to try and treat null as special with arrays, but anyone wanting to be clear
in their code should either be checking null with is (in which case, they
clearly care about null and not empty), or if they care about length == 0,
they should either be calling empty on the array or explicitly checking the
array's length, since that's what they care about. Much as having == work
with null arrays avoids issues with segfaults due to an array be unitialized
as well as avoids needing to give memory to an array just to have it be
empty, you pretty much never actually care whether an array == null. You
either care that its ptr is null (in which case, is checks that), or you
care about whether its length is 0 (in which case empty or directly checking
length checks that). arr == null is just unclear and likely buggy.

So really, there are _zero_ advantages to comparing null with ==. Using ==
with null risks adding extra overhead, and it often makes the code less
clear. On the other hand, using is makes it crystal clear what you mean and
then does exactly what you mean - check whether the variable is actually
null. So, maybe the compiler is being a bit pedantic by insisting that you
use is rather than ==, but you really should be using is and not == when
checking for null.

- Jonathan M Davis