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
