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