On Mon, 04 May 2009 20:02:01 -0400, Derek Parnell <de...@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
