is ==

[Steven Schveighoffer]

On 5/21/18 2:05 PM, Jonathan M Davis wrote:
> 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.

For me, the code smell is using arr is null (is it really necessary to 
check for a null pointer here?), for which I always have to look at more 
context to see if it's *really* right.

Even people who write == null may want to check for null thinking that 
it's how you check an array is empty, not realizing that it *doesn't* 
check for a null pointer, *AND* it still does exactly what they need it 
to do ;)

> 
> It's the same reason that
> 
> if(arr)
> 
> was temporarily out of the language.

It's similar, but I consider it a different reason. While the intent of 
== null may not be crystal clear, 99% of people don't care about the 
pointer, they just care whether it's empty. So the default case is 
usually good enough, even if you don't know the true details.

Whereas, if(arr) is checking that the pointer is null as well as the 
length is 0. Most people aren't expecting that, and those who are are 
like Andrei and Vladimir -- they know the quirks of the language here. 
For the longest time I thought it was just checking the pointer!

I think aside from the clout of the ones who wanted it, the biggest 
reason that change was reverted was that it became really difficult to 
use an array inside a conditional. One-liners had to be extracted out, 
temporary variables defined.

> 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.

If we never had null be the default value for an array, and used [] 
instead, I would be actually OK with that. I also feel one of the 
confusing things for people coming to the language is that arrays are 
NOT exactly reference types, even though null can be used as a value for 
assignment or comparison.

But it still wouldn't change what most people write or mean, they just 
would write == [] instead of == null. I don't see how this would solve 
any of your concerns.

-Steve