is ==

[IntegratedDimensions]

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.