Forbid dynamic arrays in boolean evaluation contexts

[Vladimir Panteleev]

On Tuesday, 26 March 2013 at 13:12:42 UTC, Timon Gehr wrote:
> It is simply left unspecified. Hence, relying on a distinction 
> between null and empty arrays is extremely brittle.

I think calling it "extremely brittle" based on that [] is UD is 
an exaggeration. As I've stated, I maintain a nontrivial program 
which works with non-null empty strings and arrays, and rarely 
encountered difficulties.

>> To
>> create a non-null empty array, you have to use something like 
>> (new
>> uint[1])[0..0].
>
> Sure, therefore [] is what will be used. Also, it does not 
> always work.
>
> auto x = { return (new uint[1])[0..0]; }();
> void main(){ assert(x is null); }

That looks like a CTFE bug. The same thing doesn't happen with 
strings and "".

>> The distinction being the case with a non-empty slice starting 
>> at
>> address 0?
>
> Yes. I think the conversion to bool is a leftover from when 
> arrays implicitly decayed to pointers.

When would an array with null .ptr and non-zero length make 
sense? Do we want to care about such cases? We could simply state 
that slicing NULL is undefined behavior.