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.
