Why is array truth tied to .ptr?
Bill Baxter
dnewsgroup at billbaxter.com
Mon Dec 10 01:07:13 PST 2007
Janice Caron wrote:
> On Dec 10, 2007 2:01 AM, Bill Baxter <dnewsgroup at billbaxter.com> wrote:
>> BTW, if someone does feel the current behavior is more rational or
>> functional in some way, then I'd love to hear it. Perhaps it's my
>> familiarity with Python, but I just don't get why you'd want if(array)
>> to mean anything other than if(array.length).
>
> Personally, I'd prefer if(array) to fail to compile, because I don't
> like the idea of implicit conversions to bool. That would force you to
> say what you mean - i.e. either
>
> if (array.length == 0)
>
> or
>
> if (array is null)
I also would prefer an error to the current behavior of doing something
unintuitive that looks like it works correctly but in fact does
something slightly different.
> I suspect the current behaviour really means
>
> if (array.ptr == null && array.length == 0)
I guess you are free to look at it it that way, however if you look at
the truth table I posted in the original message, the array.length == 0
is redundant there. if array.ptr is null length is always zero.
> which is not entirely unreasonable. Certainly, in the case of strings
> (as special type of array) the current behaviour allows one to
> distinguish between an unassigned string and an empty string - which
> is occasionally desirable.
If the default were changed to check array.length you could still
achieve that by explicitly checking "if(array.ptr)"
--bb
More information about the Digitalmars-d
mailing list