Forbid dynamic arrays in boolean evaluation contexts

[Daniel Murphy]

"Steven Schveighoffer" <schveiguy at yahoo.com> wrote in message 
news:op.wuibbpkbeav7ka at stevens-macbook-pro.local...
>
> I would favor just changing the behavior.  The existing behavior is most 
> often a bug when it is used, because quite often arrays are null (that is 
> the default value), and quite often, people THINK they are checking if the 
> array is empty instead of if the pointer is null.  Because most empty 
> arrays are null, and null arrays have zero length, their tests do not 
> expose this bug.  It's actually very difficult to generate a non-null 
> empty array for testing. [] does not work, it returns a null array!
>
> Only in rare cases do people actually want to check for null, and in most 
> people's code it is an error when a non-null but empty array is checked 
> with if(arr).  If people are interested in the pointer, they usually check 
> if(arr.ptr) or if(arr !is null).
>
> I would posit that for every knowledgeable person who uses this "shortcut" 
> to check for null, 100 people use it expecting it to be measuring the 
> array length.
>
> If we go through a deprecation cycle, it makes people who do if(arr) for 
> length have to change there code to if(arr.length) then back to if(arr) 
> once the deprecation is over.  The switch to if(arr.length) will be 
> simple, the compiler will show all the places if(arr) is used, but the 
> switch back will be more difficult since if(arr.length) will not be 
> deprecated.
>

There is no need to ever switch the code back.

> What about a switch that identifies all places where if(arr) is done? 
> Then people who use if(arr) for testing if(arr.ptr) can find and fix their 
> cases.  Or even a separate tool to do that.
>
> -Steve

I think the deprecation process is a better option than a switch, because it 
forces code to be fixed and gives people time to do so.  The less code we 
silently break the higher chance this has of Walter-approval.