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

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

Then don't allocate zero bytes.
> 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. 

> I never compare arrays to null if I can remember, I always check the  
> length instead, which is consistent for both null and empty arrays.

I do the same as you.

Derek Parnell
Melbourne, Australia
skype: derek.j.parnell

Reply via email to