On Wednesday, 22 April 2015 at 10:36:04 UTC, Jonathan M Davis
wrote:
> So, the obvious thing for a C programmer when they see
>
> if(arr)
>
> would be to think that it was equivalent to
>
> if(arr != NULL)
Don't you contradict yourself now?
arr!=null is equivalent to arr.length!=0
that I meant C code with that line.
If C programmers won't apply C intuition in D code, then there's
no problem?
D arrays were designed in a way that they avoid segfaults;
otherwise an
empty array and a null array would not be considered equal, and
doing stuff
like trying to append to a null array would segfault. You have
to work at it
to get a segfault with D arrays.
Hmm... if D arrays allow segfaults, that means, they don't avoid
segfaults. Empty and null arrays are considered equal because the
array comparison algorithm iterates over their contents and
compares elements one by one, if the loop passes all elements
successfully, then the slices are equal. The algorithm pays no
attention to null slices and doesn't make any precautions against
segfaults, it looks as if it assumes that slices are even
non-empty.
That doesn't mean that the optimizer does
the best job (as evidenced by 14436), but D arrays are quite
clearly
designed in a manner that avoids segfaults and conflates null
with empty as a result.
14436 is a direct consequence of absence of any special treatment
of null slices, no special attention was ever paid to null
slices, no avoidance of segfaults in any way ever existed in the
code. That's a total misconception.
