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.


Reply via email to