What about putting array.empty in object.d?

[Jonathan M Davis]

On Thursday, March 22, 2012 10:39:23 Daniel Murphy wrote:
> "Jonathan M Davis" <jmdavisProg at gmx.com> wrote in message
> news:mailman.985.1332364578.4860.digitalmars-d at puremagic.com...
> 
> > I know that. Much point is that length == 0 is a bad thing to do in
> > general,
> > because it's ineffecient with some containers. The language itself is
> > pretty
> > much irrelevant as far as that goes. As such, I'd argue in pretty much
> > _any_
> > language that using length == 0 instead of empty is _not_ a good habit to
> > be
> > in. Doing it with arrays will make it much more likely that you'll end up
> > doing it with containers without thinking about it. On the other hand, if
> > you're in the habit of _always_ using empty rather than length == 0, then
> > you
> > don't have the problem.
> 
> Yes, .length is inefficient on some containers... but so is indexing. That
> doesn't mean using indexing on arrays is a bad habit.

Except that containers shouldn't provide indexing if it's not efficient. And 
from what I've seen, it's far too common for programmers to check length == 0, 
and they end up doing it on stuff like linked lists where it _is_ inefficient. 
It's considered good practice in C++ to use empty rather than length for 
exactly the reasons that I've listed. D is no different in this regard.

> If you're writing general code for ranges, you are going to have to use the
> range interface. But when you're writing code for arrays only, you can take
> advantage of the fact that indexing is O(1), length is O(1), slicing is
> O(1) etc.

True, but save for length, those should all be O(1) (or at maybe O(log n) at 
the worst). So, save for length, those operations are supposed to be efficient 
for _any_ container.

And yes, you can do whatever you want with arrays without regard for other 
containers if you want to. My point is that if you're in the habit of using 
length == 0, you'll end up using it with stuff _other_ than arrays - including 
containers where it's very inefficient. It doesn't help that it seems to be many 
programmers' natural instinct to check whether a container's length is 0 
rather than checking whether it's empty.

Using empty rather than length == 0 is all about getting into the habit of 
doing things the efficient way so that you don't have to think about it, and 
you're less likely to make mistakes. It's the same as why you should always 
use the pre-increment operator in C++ if it doesn't matter whether you use 
pre-increment or post-increment (D's design was smart enough to avoid the 
problem). It's a habit which doesn't cost you anything and promotes efficient 
code. But length == 0 is far worse, because it can result in an operation 
costing O(n) instead of O(1) rather than having a constant cost added to it.

> I'm not even advocating using arr.length == 0 to check for empty. Just use
> `if (!arr)`.

I don't like that either, because of the potential ambiguity for newbies 
(given the whole null vs empty mess and the fact that if(var) checks for null 
with all other reference types), but at least that's not going to cost you 
anything in terms of efficiency, whereas if you're in the habit of always using 
length == 0, you're likely to use it when it would really cost you. So, 
if(arr) is more of a style choice and is more debatable, I think, whereas I'd 
consider the issue of length == 0 vs empty to be more black and white.

- Jonathan M Davis