is ==

[Steven Schveighoffer]

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

I remember this, and I remember arguing for the current behavior many 
times (after having many many crashes) :)

https://forum.dlang.org/post/fqlgah$15v2$1@digitalmars.com

Read that thread if you want to see the rationale.

However, I'd argue it's still good to keep the error as there is 
literally no point to not using == null on class references vs. is null. 
You now would get the same result, but it's faster/cleaner.

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

Some things in TDPL were forward-thinking. I remember Andrei fleshing 
out some of how the languages SHOULD behave in the forums or mailing 
lists for the purposes of writing TDPL even though it didn't yet behave 
that way. In fact, I'm almost positive the new object comparison 
function came as a result of TDPL (but I'm not 100% sure). Some of TDPL 
still has never been implemented.

Long story short, don't date the existence of features in TDPL based on 
the publication :)

In this case, for fun (what is wrong with me), I looked up the exact 
date it got added, and it was Feb 2010: 
https://github.com/dlang/druntime/commit/2dac6aa262309e75ad9b524cb4d1c3c1f0ecc2ae. 
TDPL came out in June 2010, so this feature does predate TDPL by a bit.

In fact, through this exercise, I just noticed that the reason it 
returns auto instead of bool is to make sure it gets into the now 
defunct "generated" object.di file 
(https://github.com/dlang/druntime/pull/2190).

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

It's not worth a compiler error if we didn't already have it, but I 
don't know that it's worth taking out. It's really what you should be 
doing, it's just that the penalty for not doing it isn't as severe as it 
used to be.

>> One casualty of the current state of affairs is that no object
>> may compare equal to null.

And let's keep it that way!

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

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

I hope this never happens.

-Steve