Forbid dynamic arrays in boolean evaluation contexts

[Steven Schveighoffer]

On Tue, 26 Mar 2013 19:28:44 -0400, Vladimir Panteleev  
<vladimir at thecybershadow.net> wrote:

> On Tuesday, 26 March 2013 at 22:04:32 UTC, Steven Schveighoffer wrote:
>> On Tue, 26 Mar 2013 17:31:26 -0400, Vladimir Panteleev  
>> <vladimir at thecybershadow.net> wrote:
>>
>>> On Tuesday, 26 March 2013 at 17:57:47 UTC, Steven Schveighoffer wrote:
>>>> But it definitely is NOT a bug.  Any suggested change would be an  
>>>> enhancement request.
>>>
>>> Why do you think it is not a bug? It is inconsistent with "", and  
>>> what's the point of [] if you can just use "null"?
>>
>> Meaning it functions as designed.  Whether you agree with the design or  
>> not, it's still not a bug.
>
> What I meant is: why do you think this was an intentional, thought-out  
> design decision? Where is the justification for it? I'd say it's more  
> likely it was written with no thought given to the distinction between  
> null and empty arrays.

The design is that the pointer of a 0-length array when allocating one is  
inconsequential.  Rather than allocate space on the heap or designate  
space on the data segment, null is available and free, and it happens to  
be the default you get when you declare an array.  The code is  
specifically designed to return null, see these lines in the new array  
function:

     if (length == 0 || size == 0)
         result = null;

link to github:  
https://github.com/D-Programming-Language/druntime/blob/master/src/rt/lifetime.d#L774

size being the size of the element.

I was not around when this decision was made, but it seems clear from the  
code that case was handled specifically to return null.  Seeing as null  
arrays and empty non-null arrays are functionally equivalent in every  
respect except for this weird boolean evaluation anomaly (which I think  
should be fixed), I don't see the problem.

>> And once again, "" is different because of C compatibility.  If that  
>> were not a requirement, "" would map to null.
>
> Why do you think so? Sorry, but to me it just seems like you're stating  
> personal conjecture as absolute facts.

It makes sense, why allocate any space, be it static data space or heap  
space, when null works perfectly fine?  The same decisions that lead to []  
returning null would apply to strings if C didn't have to read the  
pointed-at data.

"" isn't even consistent with itself!  For example:

teststring1.d:
module teststring1;

import teststring2;

void main()
{
    dotest("");
    dotest2();
}

teststring2.d:
module teststring2;
import std.stdio;

void dotest(string s)
{
    writeln(s == "");
    writeln(s is "");
}

void dotest2()
{
    dotest("");
}

Outputs:

true
false
true
true

I would contend that relying on pointers being a certain value is a bad  
idea for arrays unless you really need that, in which case you should have  
to be explicit.

In fact, relying on whatever [] returns being a certain pointer would be  
bad as well.  You should only rely on null pointing at null.

Any plans to make the spec *specifically* require [] being non-null would  
be an enhancement request.

> This discussion is ultimately inconsequential, because we probably can't  
> change it now as it would break code, but your certainty regarding the  
> origins of these decisions lead me to believe that you know something I  
> don't.

I wasn't there, I didn't make the decision, but it's implied in the  
existing code and the spec.

-Steve