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