is ==

[IntegratedDimensions]

On Sunday, 20 May 2018 at 00:19:28 UTC, Jonathan M Davis wrote:
> On Saturday, May 19, 2018 17:50:50 IntegratedDimensions via 
> Digitalmars-d- learn wrote:
>> 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.
>
> Not really, no. Having
>
> foo == null
>
> be rewritten to
>
> foo is null
>
> in the non-dynamic array cases should be fine except for the 
> fact that it's then a terrible habit to be in when you then 
> have to deal with dynamic arrays. Using
>
> foo == null
>
> with dyanmic arrays is an enormous code smell, because the odds 
> are extemely high that the programmer thinks that they're 
> checking if the dynamic array is null when that's not what 
> they're doing at all. IMHO, it should definitely be an error to 
> use == with null and dynamic arrays because it is such a big 
> code smell. Either the code should be using is to check whether 
> the array is null, or it should be checking length. It should 
> never be using == with null.
>
> But unfortunately, the compiler is completely backwards about 
> this and treats it as an error with pointers and references but 
> allows it with dynamic arrays. If the compiler were improved to 
> just replace == with is in the cases that it currently treats 
> as illegal, then that would be fine if it then treated it as 
> illegal with dynamic arrays. But as it stands, it is still more 
> efficient to use is with call references, so encouraging the 
> programmer to use is is benefical, and it encourages the 
> programmer to get in the habit of not using == with null, since 
> it's a terrible habit to be in with dynamic arrays. But 
> actually making it illegal for dynamic arrays would be a much 
> better approach.
>
> If it were up to me, it would just be illgal to use == with 
> null in general, because that's really the way it should be 
> with dynamic arrays, and then the language would be consistent 
> about it. But instead, the compiler screams in the case that 
> matters far less and allows it in the case that is clearly bad. 
> So, it's inconsistent in a dumb way. At least if it were 
> inconsistent by allowing it for pointers and references while 
> disallowing it for arrays, it would be prventing it in the case 
> that truly matters, but instead, what we have is just dumb.
>
> - Jonathan M Davis

Let D be a dynamic array, O a pointer or object:
           | Conceptually |  in D
D == null     Invalid       Valid
D is null     Valid         Valid
O == null     Valid         Invalid
O is null     Valid         Valid

Right?

So what you are saying is you want to create 2 more invalids in 
the table to satisfy some weird logic which requires the 
programmer to remember special cases rather than make them all 
valid and easy to remember even though it can be done and make 
sense.

In fact, the 2nd invalid makes sense and should be allowed so 
really you want to create 3 invalids for the price of one.

Simply require == null as is null and be done with it.  You can't 
police programmers minds and get them to program correctly. If 
you had a kid, do you box them up in a bubble room and not let 
them play because they might hurt themselves? How people learn is 
by making mistakes. It is better to provide a logical foundation 
that is consistent rather than produce corner cases to handle 
some corner case that was created to handle another corner case 
because someone handled a corner case.