On Saturday, 19 May 2018 at 01:31:38 UTC, Jonathan M Davis wrote:
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
I don't see your point.
You claim that one should never use == null for whatever reason
and that it is "wrong". So, why are you allowing wrong things in
a language that can easily be fixed?
Just reinterpret == null as is null and be done with it! This
fixes the wrong and everyone can live happily ever after.
Your logic is the same how people "ban" certain words like
faggot. They don't like them for some reason, decide that no one
should use it any more, and create a new word that essentially
means the same thing... and it results in a loop where that new
word then eventually gets "banned".
== vs is might not be quite as extreme, maybe is will be the
final "word". But if == null is banned by the compiler why the
hell not just reinterpret to mean is null internally and be done
with it and allow the syntax since it is so common?
The only pitfalls is pasting code from other languages that might
have a different interpretation, but those problems always exist
since the languages are different.
Your reasons for arrays is not good enough. First, not all types
are arrays so you are banning a whole class of valid types for
one case. That case, you say, is almost never meant anyways(that
is, using == null is really meant as is null).
So, ultimately what I feels like is that you are actually arguing
for == null to be interpreted as is null but you don't realize it
yet.
