is ==

[Jonathan M Davis]

On Monday, May 21, 2018 10:01:15 Steven Schveighoffer via Digitalmars-d-
learn wrote:
> On 5/18/18 9:48 PM, Jonathan M Davis wrote:
> > 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.
> I use arr == null all the time. I'm perfectly fine with that, and
> understand what it means.
>
> > Using == with null and arrays is always unclear about the programmer's
> > intent and almost certainly wasn't what the programmer intended.
>
> I beg to differ.
>
> > 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.
>
> IMO, doing anything based on the pointer of an array being null is a
> huge code smell. In which case, == null is perfectly acceptable. I'm
> comparing my array to an empty array. What is confusing about that?
>
> I actually hate using the pointer in any aspect -- an array is
> semantically equivalent to its elements, it's not important where it's
> allocated. The only place D forces me to care about the pointer is when
> I'm dealing with ranges.

The core problem here is that no one reading a piece of code has any way of
knowing whether the programmer knew what they were doing or not when using
== null with an array, and the vast majority of newbies are not going to
have understood the semantics properly. If I know that someone like you or
Andrei wrote the code, then the odds are good that what the code does is
exactly what you intended. But for the average D programmer? I don't think
that it makes any sense to assume that, especially since anyone coming from
another language is going to assume that == null is checking for null, when
it's not.

It's the same reason that

if(arr)

was temporarily out of the language. The odds are very high that the
programmer using it is using it wrong. Andrei and Vladimir were using it
correctly in their code, so they didn't like the fact that it had then
become illegal, but while knew what they were doing and were using it
correctly, plenty of other folks have been inserting bugs whenever they do
that, and if I see if(arr) or assert(arr) in code, I'm going to consider it
to be code smell just as much as I consider arr == null to be code smell.

And yes, trying to treat the ptr as being null as special with a dynamic
array is risky, and most code shouldn't be doing it, but you're almost
forced to in some cases when interacting with C code, and clearly there are
folks that do (e.g. Andrei and Vladimir). But even if we could unequivocably
say that no one should be doing it, you still have no way of knowing whether
someone is attempting it or not when they do arr == null, and since caring
whether an array is null or not is a very typical thing to do in other
languages where there is a very clear distinction between a null array and
an empty one, plenty of folks come to D expecting to be able to do the same.
And they're going to write arr == null or arr != null, and any time I see
code like that, I'm going to have sit down and figure out whether they
really meant arr is null, or whether they meant arr.length == 0, whereas if
they had just written arr is null or arr.length == 0 (or arr.empty), their
intent would have been perfectly clear. As such, I would strongly advise D
programmers to use arr.empty or arr.length == 0 instead of arr == null, even
if they know what they're doing, just like I would advise them to not treat
null as special for arrays unless they really need to.

At this point, I'm honestly inclined to think that we never should have
allowed null for arrays. We should have taken the abstraction a bit further
and disallowed using null to represent dynamic arrays. It would then
presumably still work to do arr.ptr is null, but arr is null wouldn't work,
because null wouldn't be an array, and arr == null definitely wouldn't work.
Then we could just use [] for empty arrays everywhere, and there would be no
confusion, leaving null for actual pointers. And it would almost certinly
kill off all of the cases where null was treated as special for dynamic
arrays except maybe for when dealing with C code, but in that case, they'd
have to use ptr directly. However, at this point, I expect that that's all
water under the bridge, and we're stuck with it.

- Jonathan M Davis