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.