What about putting array.empty in object.d?

[Steven Schveighoffer]

On Wed, 21 Mar 2012 16:21:21 -0400, Nick Sabalausky <a at a.a> wrote:

> "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.

They can be.  But the language doesn't define them as ranges, phobos  
does.  In order to use arrays as ranges, I have to import std.range or  
std.array.

>
>> 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.

What I meant is any container that defines ranges.  In other words, any  
time you are going to be using ranges, you import std.range.  Which makes  
array.empty work.

>> 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.

We have defined range interface requirements.  If we want to define .empty  
for everything other than ranges which can contain things, we can, but  
it's not done already.  If we wanted to do that, then I agree array.empty  
should go into object.d.

>> 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)

We have discussed ways of introducing this in the least painful way.  I  
think it should happen, no matter what the pain, since it's the least  
obvious choice.

> but I don't think it's an adequate substitute
> for array's range-style interface being available whenever arrays are
> available (ie, always).

This goes a step further, saying all the range-style interfaces for arrays  
should go into object.  I certainly don't agree with that.

-Steve