[Issue 2934] "".dup does not return empty string

[Steven Schveighoffer]

On Mon, 04 May 2009 20:02:01 -0400, Derek Parnell <derek at psych.ward> wrote:

> On Mon, 04 May 2009 17:16:45 -0400, Steven Schveighoffer wrote:
>
>
>> what's not intuitive is comparing an array (which is a struct) to null.
>
> Hmmm ... interesting. I regard the array not as a struct but as a concept
> implemented in D as a struct.

Yes, but null is a pointer.  Can I make just any struct with a pointer,  
and expect to be able to compare it to null (and have it direct that  
comparision to the pointer)?

The distinction that an array is a struct and not a pointer or reference  
is one of the frequent causes of newbie frustration, because they just  
don't get it at first.  I know of no other language that implements arrays  
like this (where the length is local, but the data is shared).

It's also one of the gems of D if you learn to use it correctly.

>
>> char[] arr1 = "";
>> char[] arr2 = null;
>>
>> assert(arr1 == arr2); // OK
>> assert(arr1 == null); // FAIL
>>
>> I'd say that comparing an array to null should always succeed if the  
>> array
>> is empty, but I guess some people may use the fact that the pointer is  
>> not
>> null in an empty array.
>
> Yes, some people rely on the distinction.
>
> However, I think that this ought to be the case ...
>
>  char[] arr1 = "";
>  char[] arr2 = null;
> assert(arr1 == arr2); // FAIL
>  assert(arr1 == null); // FAIL
>
>  assert(arr2 == ""); // FAIL
>  assert(arr2 == arr1); // FAIL
>
>  assert(null == ""); // FAIL
>
> Simply because an empty array is one with an allocation and a null array  
> is
> one without an allocation therefore they are not the same thing. So the
> '==' equality test should tell the coder that there are two different
> beasties at play here.

I would be also fine with this, as it would discourage comparing to null.   
I'd also be fine with comparing an array to null being a syntax error.   
You can always do arr.ptr == null.

> I know that there is an "efficiency" aspect to this.
>
> A "proper" test IMO is that an array is null if arr.ptr == null and
> arr.length = 0, but I suspect that will be evil to the speed aficionados.

Such an array is an anomaly, and shouldn't ever occur, unless someone  
forces it by setting the ptr specifically.  I don't think it's worth the  
extra code to cover this very rare possibility.

>>  I definitely don't want the runtime to allocate
>> blocks of data when requested to allocate 0 bytes.
>
> Then don't allocate zero bytes.

Sometimes, you don't know whether it's going to be zero bytes or not until  
runtime.  I don't want to have to check for zero-length arrays everywhere  
I dup, when the GC does it for me.

>
>> In any case, this bug is not valid, because the compiler acts as  
>> specified
>> by the spec.
>
> I'm having trouble locating the specification for this.

As far as the "" being not null, the spec does talk about it (although  
indirectly) as I cited in the original bug resolution.  As far as  
returning a null array when allocating zero bytes, there is nothing I  
could find in the spec, but this means it's up to the implementer.  So the  
implementation does not violate the spec, and it can be considered desired  
behavior, not an accident.

I'd be interested to know what Walter had in mind.

-Steve