What about putting array.empty in object.d?

[Nick Sabalausky]

"Steven Schveighoffer" <schveiguy at yahoo.com> wrote in message 
news:op.wbjc7au8eav7ka at localhost.localdomain...
>
> I don't see why defining empty in object.d is necessary for things that 
> don't involve ranges at all.
>

But arrays *are* ranges. Or at least they're supposed to be.

> Any time you import a container, it's going to import std.range, which 
> publicly imports std.array.
>

Arrays and AAs *are* containers, but you *don't* import them.

> Bottom line: if you don't care about ranges, if(array) works just fine 
> (checks if length != 0).  If you care about ranges, you are going to be 
> importing std.range and therefore std.array, and array.empty works just as 
> well.
>

Yes, but a better bottom line would be:

If you want to check if something has no elements, use "empty". Period. 
Done.

Why should it even matter whether it's an array vs some other range? Why 
can't checking for empty be standardized and consistent? It's a simple and 
fundamental enough concept.

> As an bonus this gets rid of the controversial behavior of if(array) 
> translating to if(array.ptr).
>

Yea, I'm not *necessarily* opposed to "if(array)" translating to 
"if(array.length != 0)" (athough it would break code that relies on the 
"null vs empty" distinction), but I don't think it's an adequate substitute 
for array's range-style interface being available whenever arrays are 
available (ie, always).