[phobos] std.array.ilength

[Andrei Alexandrescu]

I don't see a problem with using size_t throughout. The machine will be 
as good or better at operating on size_t (compared to int).

The size argument has been historically made about double and float. 
Today people use double throughout and float on occasion when they want 
to optimize storage.

@Don: Making it signed adds insult to injury. It means that we're 
inconsistent about the way we handle nonnegative entities in the 
language and its library.


Andrei

On 2/17/11 4:46 PM, David Simcha wrote:
> On Thu, Feb 17, 2011 at 5:28 PM, Andrei Alexandrescu <andrei at erdani.com
> <mailto:andrei at erdani.com>> wrote:
>
>     I assume I'm in the minority here, but I don't see a need for such a
>     function.
>
>     Andrei
>
>
> The point you're missing is that arrays are a very commonly used thing
> and give you no choice about integer widths.  Most of the time, if you
> don't need the extra width (most values in any program represent
> quantities that can't plausibly be bigger than the maximum value of some
> fixed-width integer) and want to avoid either the viral effects of using
> wide integers or the need to insert casts all over the place, you just
> use a narrower integer.  For the vast majority of quantities people deal
> with, 32-bit ints are more than enough, so they tend to be what's used
> most in practice.
>
> With arrays, you don't have that choice, even though the *vast* majority
> of the time int is plenty and you tend to know when it isn't.
> Therefore, you get stuck either dealing with the viralness of
> array.length being a ulong on 64 or with the ugliness of manually
> inserting casts everywhere.  You gain virtually nothing in safety in
> exchange because arrays are almost never (and when I say almost never I
> mean I've never seen one in my life) over 2 billion elements long.
>
> The point is that by adding this function you lose epsilon in safety,
> where epsilon is some tiny but nonzero value, and gain a whole bunch in
> usability.  Realistically, using size_t everywhere is not a good idea
> (though it admittedly is a good idea in a large portion of cases) for
> *at least* two reasons, i.e. two that I've encountered already:
>
> 1.  Storing arrays of indices into other arrays with size_t's is
> incredibly wasteful unless there's a realistic chance that one of the
> arrays you're indexing could be billions of elements long.
>
> 2.  Some libraries written in other languages that interface with D
> (GTK, BLAS and LAPACK come to mind) always assume, even on 64, that int
> is enough for the length of an array.  The ugliness and tediousness of
> putting casts everywhere to accommodate this is slowly breeding insanity
> in me.
>
> --Dave
>
>
>
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos