is ==

[IntegratedDimensions]

On Sunday, 20 May 2018 at 02:09:47 UTC, Jonathan M Davis wrote:
> On Sunday, May 20, 2018 01:51:50 IntegratedDimensions via 
> Digitalmars-d- learn wrote:
>> Simply require == null as is null and be done with it.
>
> That would be flat out wrong for dynamic arrays, because then
>
> auto result = arr == null
>
> and
>
> int[] nullArr;
> auto result = arr == nullArr;
>
> would have different semantics. The way that dynamic arrays are 
> designed to work even if they're null mucks with this 
> considerably here.
>

Do you not see they are different?

You think

arr == nullArr

and

arr == null

are suppose to necessarily be the same semantics? That is 
patently false! You should rethink your position on that because 
it is wrong. null is a keyword in D and has a very special 
meaning and hence that meaning MUST be taken in to account.

There is no harm in making them different. Your logic thinks that 
that they should be the same but if you are wrong then your whole 
argument is wrong.

for example,

Object o = null;

then

o == null

should not be true even though "null == null" in some sense.

== null is a test of validity. One never checks if null == null 
and it is a meaningless case so allowing it as a possibility is 
meaningless.


You are treating null as if it is on the same level as objects 
and arrays and it is not. By doing so you lose the power of it 
being singled out as a keyword.


>> You can't police programmers minds and get them to program 
>> correctly.
>
> That's true, but making things that are highly likely to be 
> wrong illegal prevents bugs. e.g.

Not necessarily because you just create more bugs by doing that. 
Your son, the bubble boy, then does not develop an immune system 
that he should of developed by you trying to protect them from 
hurting himself.

You should get out of the business of trying to prevent things 
that you don't even know are going to happen. It is a bad mindset 
to be in because, for all you know, those things will never 
happen. Time is better spent than trying to police everyone from 
doing anything wrong. 1. You can't do it. 2. You make things 
worse in the long run because who's policing you to keep you from 
screwing up?

Do you know how many "bugs" are produced by people who are fixing 
"bugs"? We can surely bet more than zero.

> while(cond);
>
> is illegal in D precisely because it's error-prone. There are 
> cases where doing something like that would be perfectly 
> correct. e.g.
>
> while(++a != b);
>
> but you can do the exact same thing with empty parens
>
> while(++a != b) {}
>
> and all of those bugs with accidentally closing a loop with a 
> semicolon go away, and you don't lose any expressiveness. The 
> compiler just forces you to write it in a way that's far less 
> error-prone.

This is a different problem and therefor not applicable.

> Making it illegal to compare the null literal with == also 
> prevents bug, and you don't lose any expressiveness doing it 
> either. It's the same kind of logic. Making error-prone 
> constructs illegal when there's a simple equivalent that isn't 
> error-prone is good language design, because it prevents bugs 
> without actually restricting the programmer. It's when the 
> language starts disallowing things that aren't error-prone 
> and/or don't have simple equivalents that you start running 
> into problems with the compiler getting in your way and 
> treating you like a kid. For simple stuff like this, it 
> ultimately saves you time and effort without getting in your 
> way. At most, you occasionally have to replace foo == null with 
> foo is null or foo.length != 0, and it potentially saves you 
> hours of effort tracking down a subtle bug.
>
> - Jonathan M Davis

You certainly do lose expressiveness. You loose elegance because 
you cannot express logically related things in a logically 
related way.

The problem is the WHOLE reason it is error prone is from who 
ever decided the dynamic array syntax of == null would not 
compare it the same way it does everything else.

Basically someone thought they were going to be fancy and treat 
== null as the same as an allocated 0 length array. That was the 
problem from the get go.

== null should have a very specific and consistent meaning and 
someone decided to change that in an irregular and inconsistent 
meaning and now we have less elegance in the language than we 
could.

The reason why you are saying it is buggy is PRECISELY because of 
what was done wrong. Programmers assume that == null means the 
same thing it does everywhere else, but LO AND BEHOLD! Not in 
that one special case and if they don't know about that special 
case they hit the "bug".

See, what you call bugs is really the programmers failing to know 
the special case that was created. The special case that really 
had no reason to be a special case. So, in fact, who ever decided 
on the rules here created more problems than they solved.

Any time you create special cases you create complexity and that 
is what creates bugs of the type here. These bugs are entirely 
preventable with proper thought out consistency and these bugs 
are not the programmers fault but bugs in the design of the 
language, which are far worse. These are not the same types of 
bugs like a syntax error or a logic bug.