[phobos] std.array.ilength

[Jonathan M Davis]

On Thursday, February 17, 2011 15:31:01 Andrei Alexandrescu wrote:
> On 2/17/11 5:10 PM, David Simcha wrote:
> > Have you actually tried porting any application code to 64? Phobos and
> > other similarly generic libraries don't count because code that's that
> > generic legitimately can't assume that no arrays are going to be
> > billions of elements long.
> 
> Code that uses the unrecommended practice of mixing int and uint with
> size_t everywhere will be indeed difficult to port to 64 bits. But
> that's a problem with the code, and giving that unrecommended practice
> legitimacy by making it look good is aiming at the wrong target.
> 
> Use size_t for sizes and it's golden. You can't go wrong. On the rare
> occasions when you want to store arrays of indexes, do the cast by hand,
> don't ask the standard library to give it a nice face by making the
> assumption for you.

I concur. If you use auto and/or size_t, it's rarely a problem that size_t 
changes its size based on the architecture. Using int or uint for indices is 
generally wrong. If you really need it to be an int or uint, then a cast should 
be used. And if you're really running into this problem all over the place, 
because you frequently save array indices (which I would posit is _not_ 
something which is normally done very often, let alone in a manner that it would 
be a problem just to save them as size_t), then you can create ilength in your 
own code. But I really think that not only would ilength promote poor practices, 
but it would generally lead to less maintainable code, because it would be 
_really_ easy to mix up ilength and length.

And honestly, I would say the fact that someone is running into errors with 
array indices in 64-bit land, because they weren't using size_t is just showing 
that the code was faulty to begin with. They should have been using size_t. At 
least the compiler will now point it out to them.

- Jonathan M Davis