No subject

But there are two counter arguments:

1. Comparing an array to null has limited utility, I don't think it should be
in widespread use, as most of the time you only care if the array is empty or
not.  There may be special cases, but in those cases, you can use arr.ptr ==
null.  It would have been much better if arr == null never compiled.

2. Duping an empty array has limited defensive utility.  You can just as easily
return the array itself.  If it weren't for the horrendous append behavior, it
would be a no brainer:

T[] edup(T)(T[] arr)
{
   return arr.length == 0 ? arr : arr.dup;
}

usage:

return arr.edup();

Allocating data for duping an empty array is not an acceptable pessimization. 
However, I thought of another possible solution:  A dup of an empty, non-null
array can return a pointer into the read only data segment.  This would allow a
non-allocation on duping an empty array, would not return a pointer to null,
and would not accidentally overwrite the original array if appending is done.

So a fix can be done.


--