string <-> null/bool implicit conversion

[Steven Schveighoffer via Digitalmars-d]

On 8/20/15 3:04 PM, "=?UTF-8?B?Ik3DoXJjaW8=?= Martins\" 
<marcioapm at gmail.com>\"" wrote:
> On Thursday, 20 August 2015 at 18:42:56 UTC, Márcio Martins wrote:
>> On Thursday, 20 August 2015 at 18:04:00 UTC, Steven Schveighoffer wrote:
>>> On 8/20/15 1:50 PM, Steven Schveighoffer wrote:
>>>
>>>> The "truthiness" of an array says it's true ONLY if both the pointer
>>>> and
>>>> length are 0.
>>>
>>> Ugh, *false* only if they are both 0. If either are not zero, then
>>> it's true.
>>>
>>> -Steve
>>
>> In other words, it's true when the pointer is not null. i.e. in the
>> context of boolean evaluation, it has the semantics of string.ptr

Pragmatically speaking, yes. Technically, both are compared, but there 
are very very few cases of the array having null pointer and non-zero 
length.

>>
>> It's just making the concept of an empty array a grey cloud.
>>
>> Consider this:
>>
>> string a = "";
>> string b;
>>
>> writeln(a ? "a" : "null");
>> writeln(b ? "b" : "null");
>> writeln(a.idup ? "adup" : "null");
>> writeln(b.idup ? "bdup" : "null");
>>
>> Output:
>> a
>> null
>> null
>> null
>>
>>
>> What?

Yep. Just don't use the truthiness of arrays (including strings) and you 
will be ok. Use a.length ? "a" : "null" instead (e.g.).

I haven't used an array as a boolean in years because of this issue, I 
always specify whether I want pointer or length checked.

>
> Also, consider this:
>
> writeln(a ? true : false);
> writeln(a && a.idup);
>
> Output:
> true
> false
>
> What?

Yep :)

> Should we consider this weird semantics and live with it, as there is
> nothing we can do, or is it a bug in idup()?

Not a bug, idup should not consume a heap block to hold 0 elements, 
returning null is correct. Again, the issue is not idup, but the 
consideration of what the truth value of the array is.

-Steve