--- Comment #7 from Steven Schveighoffer <> 2011-07-19 
05:32:02 PDT ---
(In reply to comment #5)
> In pretty much every other language that I've ever used, null is _not_ the 
> same
> thing as empty _ever_. Someone coming from C, C++, Java etc. is going to 
> expect
> dynamic arrays to be able to be null. The way that you check for null in all 
> of
> those languages is either == 0 or == null (or == NULL or == nullptr).

php just uses if(!arr) or if(arr == array()) or if(arr == null).  All of those
return true for empty arrays.

But the point I was making is, for D null *is* synonymous with empty.  D is not
every other language, and shouldn't be bound to the rules of those languages. 
The larger question to answer here is, is it likely to be *wrong* when someone

if(arr == null)

and expects this to check if the pointer is null.  The answer is very much no. 
It's likely to be either *exactly* what you want, or harmless.  The
super-subtle difference between null arrays and empty-but-not-null arrays is
seldom, if ever, used.  Now, I agree that we could have a better built-in
moniker for is this array empty, but do we really need a warning?  The code is
clear, unambiguous, and exactly what the developer wanted, or close enough to
be effective.

In java or C, checking an array for a null pointer is needed because an
unallocated array throws an exception or segfault if you try to use it.  This
is not the case in D.  D does not have this problem.  Anyone's code who thinks
it does is bound to be obvious:

if(arr == null)
   arr = new int[5];

No need to warn here, the code is fine (works exactly how the user wants).  But
the easy optimization is just to remove the if check.

> is does
> not exist in any other language that I've ever seen.

It exists in at least C# (Object.ReferenceEquals), php (===) and C has no need
for it, since operators can't be overloaded.

> I fully expect programmers
> from C, C++, Java etc. to expect == null to be checking whether an array is
> null - that is whether is null is true. But it doesn't do that. It checks
> whether length == 0.

Yeah, but the point I'm trying to make is, checking for an actual null pointer
means nothing in D!  So checking if an array is empty is a much more useful
implementation.  Null arrays are not bad things in D, they don't throw
exceptions or segfaults simply because they are null.  If anything, the check
for null is probably extraneous, and can be removed.

> But I really think that == null is a problem which is going
> to throw off a lot of people. If I see it in code, I'm either going to point 
> it
> out or change it (depending on the circumstances). The odds are just too high
> that it doesn't do what the programmer intended or that someone else reading
> the code will misinterpret what it does.

I completely disagree, the odds are very low that it's damaging or incorrect at
all.  Experienced D coders use this feature all the time.  You just gotta start
thinking in D instead of your previous languages.

Configure issuemail:
------- You are receiving this mail because: -------

Reply via email to