On Thu, 17 Feb 2011 13:08:08 -0500, bearophile <bearophileh...@lycos.com>
wrote:
Steven Schveighoffer:
Yes, David has proposed a corrected version on the Phobos mailing list:
http://lists.puremagic.com/pipermail/phobos/2011-February/004493.html
I suggest it to return a signed value, like an int. But a signed long is
OK too.
I suggest a name as "len" (or "slen") because I often write "length"
wrongly.
This isn't replacing length, it is in addition to length (which will
continue to return size_t).
Does it support code like:
auto l = arr.len;
arr.len = 10;
arr.len++;
arr.length = 10 already works. It's int l = arr.length that doesn't.
if arr.length++ doesn't work already, it should be made to work (separate
bug).
A big problem: it's limited to arrays, so aa.len or rbtree.len, set.len,
etc, don't work. So I'd like something more standard... So I am not sure
this is a good idea.
The point is to avoid code like cast(int)arr.length everywhere you can
safely assume arr.length can fit in a (u)int.
This case is extremely common for arrays, you seldom have an array of more
than 2 or 4 billion elements.
For other types, the case might not be as common, plus you can add
properties to other types, something you cannot do to arrays.
As far as I'm concerned, this isn't going to affect me at all, I like to
use size_t. But I don't see the harm in adding it.
-Steve
