On Tue, 26 Mar 2013 13:34:02 -0400, Vladimir Panteleev <vladimir@thecybershadow.net> wrote:

> On Tuesday, 26 March 2013 at 17:32:12 UTC, Jonathan M Davis wrote:
>> On Tuesday, March 26, 2013 12:24:56 Vladimir Panteleev wrote:
>>> [] (the literal) has .ptr as null. That may or may not be a bug.
>>
>> As I understand it, it's very much on purpose. It avoids a needless memory
>> allocation.
>
> In the same way that "" allocates memory?
>
> [] can be an empty slice of *anything*, but it might as well be a 0-length constant in the data segment, similar to "".

"" needs to point to the data segment because it has to point to a readable 0 character for C compatibility.  The same is not true for [].

The code for [] is modifiable without changing the compiler, you certainly can suggest something different.  I think the function is _d_newarray, there may be more than one version (one that is for 0-initialized data, one that is not).  Changing it will probably break code that depends on it being null (intentionally or not).

But it definitely is NOT a bug.  Any suggested change would be an enhancement request.

-Steve

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"?

On Tue, 26 Mar 2013 17:31:26 -0400, Vladimir Panteleev <vladimir@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.

And once again, "" is different because of C compatibility.  If that were not a requirement, "" would map to null.  There is no such requirement for general slices.

-Steve

On 03/26/2013 10:31 PM, Vladimir Panteleev 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"?

IOW, what is the point of "null" if you can just use [].

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@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.

> 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.

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.

Timon Gehr:

> IOW, what is the point of "null" if you can just use [].

I usually prefer to use [], because null is a literal for pointers and class references, while [] is a literal specific for arrays (and strings), so its meaning is more clear (in D I'd even like a [:] literal that represents an empty associative array).

On the other hand if you compile a program that uses null instead of [] you see some differences. In the current dmd compiler returning null is more efficient. I have seen code where this difference in performance matters:


int[] foo() {
    return [];
}
int[] bar() {
    return null;
}
void main() {}



_D4temp3fooFZAi:
L0:     push    EAX
        mov EAX,offset FLAT:_D11TypeInfo_Ai6__initZ
        push    0
        push    EAX
        call    near ptr __d_arrayliteralTX
        mov EDX,EAX
        add ESP,8
        pop ECX
        xor EAX,EAX
        ret

_D4temp3barFZAi:
        xor EAX,EAX
        xor EDX,EDX
        ret

Bye,
bearophile

On Tue, 26 Mar 2013 19:28:44 -0400, Vladimir Panteleev <vladimir@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@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

On Tue, 26 Mar 2013 18:56:07 -0400, Timon Gehr <timon.gehr@gmx.ch> wrote:

> On 03/26/2013 10:31 PM, Vladimir Panteleev 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"?
>
> IOW, what is the point of "null" if you can just use [].

One could say why have null if you can just use T[].init.  It's two names for the same thing, not uncommon in programming.

In this case, however, I think handling or allowing [] is good for generic code.  The question then becomes what should [] return?  To have it return null seems acceptable to me -- the default empty array is null, and null behaves quite well as a zero-length array.  The spec allows for it, and it's free to use null.

-Steve

On Tuesday, 26 March 2013 at 23:57:32 UTC, bearophile wrote:
> Timon Gehr:
>
>> IOW, what is the point of "null" if you can just use [].
>
> I usually prefer to use [], because null is a literal for pointers and class references, while [] is a literal specific for arrays (and strings), so its meaning is more clear (in D I'd even like a [:] literal that represents an empty associative array).
>
> On the other hand if you compile a program that uses null instead of [] you see some differences. In the current dmd compiler returning null is more efficient. I have seen code where this difference in performance matters:
>
>
> int[] foo() {
>     return [];
> }
> int[] bar() {
>     return null;
> }
> void main() {}
>
>
>
> _D4temp3fooFZAi:
> L0:     push    EAX
>         mov EAX,offset FLAT:_D11TypeInfo_Ai6__initZ
>         push    0
>         push    EAX
>         call    near ptr __d_arrayliteralTX
>         mov EDX,EAX
>         add ESP,8
>         pop ECX
>         xor EAX,EAX
>         ret
>
> _D4temp3barFZAi:
>         xor EAX,EAX
>         xor EDX,EDX
>         ret
>
> Bye,
> bearophile

That is a compiler bug isn't it ?

deadalnix:

>> On the other hand if you compile a program that uses null instead of [] you see some differences. In the current dmd compiler returning null is more efficient. I have seen code where this difference in performance matters:
> ...
> That is a compiler bug isn't it ?

I don't know. Maybe it's just a missed optimization :-)

Bye,
bearophile