Checking if a string is null

[Frits van Bommel]

Derek Parnell wrote:
> On Wed, 25 Jul 2007 19:01:57 +0200, Frits van Bommel wrote:
> 
>> Since null arrays have length 0, they *are* empty arrays :P.
> 
> Not in my world. I see that null arrays have no length. That is to say, the
> do not have any length, which is different from saying they have a length
> and that length is zero.

But the fact of the matter is, 'T[] x = null;' reserves space for the 
.length and sets it to 0. If you have a suggestion for a different value 
to put there, by all means make it.
Or would you prefer a segfault or diagnostic when accessing 
(cast(T[])null).length? That'd introduce overhead on every .length 
access (unless the compiler can statically determine whether an array 
reference is null).

>>> All that I would like changed is for the compare, in the case of length 
>>> == 0, to check the data pointers, eg.
>>>
>>>  > int opEquals(T)(T[] u, T[] v) {
>>>  >     if (u.length != v.length) return false;
>>>       if (u.length == 0) return (u.ptr == v.ptr);
>>>  >     for (size_t i = 0; i < u.length; i++) {
>>>  >         if (u[i] != v[i]) return false;
>>>  >     }
>>>  >     return true;
>>>  > }
>>>
>>> This should mean "" == "" but not "" == null, likewise null == null but 
>>> not null == "".
>> Let's look at this code:
>> ---
>> import std.stdio;
>>
>> void main()
>> {
>>      char[][] strings = ["hello world!", "", null];
>>
>>      foreach (str; strings) {
>>          auto str2 = str.dup;
>>          if (str == str2)
>>              writefln(`"%s" == "%s" (%s, %s)`, str, str2, str.ptr, 
>> str2.ptr);
>>          else
>>              writefln(`"%s" != "%s" (%s, %s)`, str, str2, str.ptr, 
>> str2.ptr);
>>      }
>> }
>> ---
>> The output is currently (on my machine):
>> =====
>> "hello world!" == "hello world!" (805BE60, F7CFBFE0)
>> "" == "" (805BE78, 0000)
>> "" == "" (0000, 0000)
>> =====
>> Your change would change the second line (even if it actually allocated 
>> a new empty string like you probably want instead of returning null). 
>> How would that be consistent in any way?
> 
> Your example is misleading for at least two reasons:
> ** The '==' operator compares the contents of the strings. A null string
> has no content so there is nothing to compare. This should fail but is
> doesn't in the current D. It should fail in the same manner that a null
> object reference fails the '==' operator.

This wasn't the point of the example. I could have left out the third 
element and change the .dup in the second line to a different empty 
string (f.e. a 0-length slice of the first one) and the point would 
remain the same: the proposed change would break comparison by '==' for 
empty non-null strings.

> ** The output is 'writefln' attempt at given a string representation of the
> data presented. It (aka Walter) has decided that the string representation
> of a null array is an empty string. This does not mean that a null array is
> an empty strng but just that writefln represents it as such.

Like I said, the point of the example didn't actually have anything to 
do with null strings, but rather with a bug in a change Regan proposed 
to make null strings and non-null empty strings compare unequal, which 
resulted in non-null empty strings comparing unequal.