if(arr) now a warning
Jonathan M Davis via Digitalmars-d
digitalmars-d at puremagic.com
Sun Apr 19 01:05:36 PDT 2015
On Friday, April 10, 2015 09:27:55 w0rp via Digitalmars-d wrote:
> I think it's worth changing this.
>
> if (arr)
>
> translating to
>
> if (arr.length == 0)
>
> Is immediately obvious for anyone coming from at least a Python
> background. I have implemented my own hashmaps in a similar way.
> For my maps, the length is stored in the map so it can be
> retrieved in O(1) time, and cast(bool) results in map.length ==
> 0. (This extends also to empty sets.)
>
> If we need a deprecation path, we can do it. We just warn about
> if (arr) for a while, so you are told to use if(arr.length == 0)
> or if (arr.ptr is null) for a while, then we change the behaviour
> in another release.
I agree with the change, because the current behavior is error-prone.
However, I'd just as soon leave if(arr) as illegal so that there's no
confusion over it later. Just because one set of folks think that if(arr) is
clearly equivalant to if(arr.length != 0) doesn't mean another set of folks
will - especially if it's based on what other languages are up to. For
instance, while python folks might think that it would be intuitive if
if(arr) were equivalent to if(arr.length != 0), the C folks would think that
the current behavior of it being equivalent to if(arr is null) would be more
intuitive, since they're used to thinking of arrays as pointers. By simply
forcing folks to be explicit and say if(arr.length != 0) or if(arr is null),
we avoid the problem entirely.
- Jonathan M Davis
More information about the Digitalmars-d
mailing list