Forbid dynamic arrays in boolean evaluation contexts

[Timon Gehr]

On 03/26/2013 12:24 PM, Vladimir Panteleev wrote:
> On Tuesday, 26 March 2013 at 08:15:05 UTC, Timon Gehr wrote:
>> On 03/26/2013 03:21 AM, Vladimir Panteleev wrote:
>>> ...
>>>
>>> I use this feature in the same way that anyone uses a nullable type.
>>> It's the same distinction between a pointer to struct that is null, or
>>> that is pointing to an instance containing the struct's .init. It's the
>>> same distinction between a value type T and the benefits of Nullable!T.
>>> "null" is usually used to indicate the absence of a value, as opposed to
>>> an empty value.
>>>
>>
>> It is not the same distinction. It is not like that for dynamic arrays!
>>
>> void main(){ assert(null is []); }
>
> [] (the literal) has .ptr as null. That may or may not be a bug.

It is simply left unspecified. Hence, relying on a distinction between 
null and empty arrays is extremely brittle.

> 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); }

> The "" literal does not have this problem.
>

Indeed, because it is guaranteed to be zero-terminated.

>>> Although I can see how this can trip up new users of D, personally I
>>> prefer things to be just the way they are now. That said, I wouldn't be
>>> against forcing one to write "s is null", if the consensus was that this
>>> would improve D.
>>
>> "s.ptr is null", actually
>
> 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.