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.
