[Issue 2934] "".dup does not return empty string
Derek Parnell
derek at psych.ward
Mon May 4 17:02:01 PDT 2009
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
More information about the Digitalmars-d-bugs
mailing list