Integer conversions too pedantic in 64-bit

[Steven Schveighoffer]

On Thu, 17 Feb 2011 13:08:08 -0500, bearophile <bearophileHUGS at 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