if(arr) now a warning

[Kagamin via Digitalmars-d]

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.