On Tue, 26 Mar 2013 23:21:35 -0400, deadalnix <deadalnix@gmail.com> wrote:

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

No.  [] calls the hook for _d_arrayliteral, whose source is not known at compile time.  Runtime functions cannot be inlined, which will be set in stone once the runtime is a dynamic library.

-Steve

On Wednesday, 27 March 2013 at 03:26:59 UTC, Steven Schveighoffer wrote:
> On Tue, 26 Mar 2013 23:21:35 -0400, deadalnix <deadalnix@gmail.com> wrote:
>
>> 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 ?
>
> No.  [] calls the hook for _d_arrayliteral, whose source is not known at compile time.  Runtime functions cannot be inlined, which will be set in stone once the runtime is a dynamic library.
>
> -Steve

The compiler know the result by advance, it don't need the source of the _d_arrayliteral.

On Tue, 26 Mar 2013 23:31:03 -0400, deadalnix <deadalnix@gmail.com> wrote:

> On Wednesday, 27 March 2013 at 03:26:59 UTC, Steven Schveighoffer wrote:
>> No.  [] calls the hook for _d_arrayliteral, whose source is not known at compile time.  Runtime functions cannot be inlined, which will be set in stone once the runtime is a dynamic library.
>>
>
> The compiler know the result by advance, it don't need the source of the _d_arrayliteral.

The value of the empty literal is an implementation detail, not defined by the compiler or spec as far as I know.

-Steve

On 03/27/2013 05:06 AM, Steven Schveighoffer wrote:
> On Tue, 26 Mar 2013 23:31:03 -0400, deadalnix <deadalnix@gmail.com> wrote:
>
>> On Wednesday, 27 March 2013 at 03:26:59 UTC, Steven Schveighoffer wrote:
>>> No.  [] calls the hook for _d_arrayliteral, whose source is not known
>>> at compile time.  Runtime functions cannot be inlined, which will be
>>> set in stone once the runtime is a dynamic library.
>>>
>>
>> The compiler know the result by advance, it don't need the source of
>> the _d_arrayliteral.
>
> The value of the empty literal is an implementation detail, not defined
> by the compiler or spec as far as I know.
>
> -Steve

Therefore it is currently a valid optimization to replace it by null, no matter what the runtime does.

On Wednesday, 27 March 2013 at 03:03:13 UTC, Steven Schveighoffer wrote:
> 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.

Allocating space on the heap?? You don't need to "designate" space anywhere - on the heap, stack, or data segment, because an empty array takes NO space. As I said before, ANY value for .ptr other than null would be good, even if it's cast(T*)1. What .ptr is pointing at is irrelevant, since the slice has 0 length, and indexing it with any index would be an out-of-bounds array access.

> The code is specifically designed

No. The code is specifically WRITTEN. For the third time: You don't know if this was a conscious design decision made with the distinction between null and empty arrays in mind, so please stop wording things like it was.

> I was not around when this decision was made, but it seems

> I wasn't there, I didn't make the decision, but it's implied in

This is what I wanted to clear up. Your previous posts were worded in such a way that you seemed absolutely certain of the reasonings for why the code ended up like that.

Many arguments in either direction could be presented by either side, but it doesn't change the fact that we don't know whether the current state of things was a result of careful planning or not. I could also present lengthy arguments in favor of why making [] have a non-null .ptr would have made more sense, and why I think that code's author disregarded the distinctions of non-null empty arrays, but as I said in my previous post, even if we knew the answers, they wouldn't change anything, as we can't change []'s behavior now.

On Wed, 27 Mar 2013 07:27:01 -0400, Timon Gehr <timon.gehr@gmx.ch> wrote:

> On 03/27/2013 05:06 AM, Steven Schveighoffer wrote:
>> On Tue, 26 Mar 2013 23:31:03 -0400, deadalnix <deadalnix@gmail.com> wrote:
>>
>>> On Wednesday, 27 March 2013 at 03:26:59 UTC, Steven Schveighoffer wrote:
>>>> No.  [] calls the hook for _d_arrayliteral, whose source is not known
>>>> at compile time.  Runtime functions cannot be inlined, which will be
>>>> set in stone once the runtime is a dynamic library.
>>>>
>>>
>>> The compiler know the result by advance, it don't need the source of
>>> the _d_arrayliteral.
>>
>> The value of the empty literal is an implementation detail, not defined
>> by the compiler or spec as far as I know.
>>
>> -Steve
>
> Therefore it is currently a valid optimization to replace it by null, no matter what the runtime does.

This is true, but it doesn't make this issue a bug.  It's just a missed optimization.

-Steve

On Wed, 27 Mar 2013 08:18:34 -0400, Vladimir Panteleev <vladimir@thecybershadow.net> wrote:

> On Wednesday, 27 March 2013 at 03:03:13 UTC, Steven Schveighoffer wrote:
>> The code is specifically designed
>
> No. The code is specifically WRITTEN. For the third time: You don't know if this was a conscious design decision made with the distinction between null and empty arrays in mind, so please stop wording things like it was.

Well, somebody wrote the code that way.  Whether they considered possibly pointing at a non-null value or not, I don't know.  But I assume they picked null from convenience and from the fact that nulls are a perfectly valid spot to point at for an empty array.

To say it is a bug is incorrect -- the spec does not call for null or non-null, the design is perfectly valid given the constraints.

>> I was not around when this decision was made, but it seems
>
>> I wasn't there, I didn't make the decision, but it's implied in
>
> This is what I wanted to clear up. Your previous posts were worded in such a way that you seemed absolutely certain of the reasonings for why the code ended up like that.

I can only go on what I see in the code.  It seems certain that whoever wrote it is deliberately returning null.  It's also REQUIRED by the spec for "" to return a pointer to a readable 0, so null is not possible.  I can only assume, with a very high degree of certainty, that if that requirement was gone, "" would also return null given the behavior of the array literal code, and the assumption the same developer wrote both.

I am not 100% certain, as I didn't write the code, I guess you caught me?  It's more like 99% certain.  This of course is my opinion.

-Steve

On Wednesday, 27 March 2013 at 12:18:35 UTC, Vladimir Panteleev wrote:
> No. The code is specifically WRITTEN. For the third time: You don't know if this was a conscious design decision made with the distinction between null and empty arrays in mind, so please stop wording things like it was.
>

Well that is not sure. I don't have the answer.

BUT !

In D, you'll find many places where identity and value are conflated. This is one instance of the problem. This is pretty bad in general.

implicit cast to bool usually imply using the value (otherwise, an int would always cast to true) and it is rather surprising that it does check for identity for slices.