On Wed, 21 Mar 2012 16:21:21 -0400, Nick Sabalausky <a@a.a> wrote:
"Steven Schveighoffer" <schvei...@yahoo.com> wrote in message
news:op.wbjc7au8eav7ka@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
