Has truth of arrays always acted like this?

[Kris]

Well, I sure hope that /never/ happens. A null is a null (the array .ptr and 
.length are both zero), while an empty string is perfectly valid.

tip: faster way (on 32bit platforms) to check for null array is to test the 
.ptr only, since it's 32 bits rather than 64.


"Mike Parker" <aldacron71 at yahoo.com> wrote in message 
news:feuj8s$1kjt$1 at digitalmars.com...
> Bill Baxter wrote:
>> Bill Baxter wrote:
>>> I could have sworn there was a big discussion just recently about how 
>>> "null" and "empty" were the same thing with D arrays and some people 
>>> were arguing that should change.  But at least with the most recent D 
>>> v1.022, it seems the truth value of uninitialized and empty arrays *are* 
>>> different.  Has it always been that way?
>>
>> I think maybe the discussion I was remembering was about comparison with 
>> null.  Indeed (a==null) is true for both uninitialized *and* length==0 
>> arrays.
>>
>> That seems completely backwards to me.  If anything, a==null should be 
>> the one that checks if a has a buffer allocated at all, and if(a) should 
>> be the one that checks for any form of emptiness.
>>
>> Barring that, they should just behave the same.
>>
>> --bb
>
> I recall a recent discussion specifically about empty vs. null strings, 
> i.e. an empty string ("") is equivalent to a null string:
>
> char[] s1 = "";
> char[] s2 = null;
>
> if(s1 == s2) writefln("equal");
>
> This will evaluate to true.