[phobos] std.array.ilength
David Simcha
dsimcha at gmail.com
Thu Feb 17 14:46:10 PST 2011
On Thu, Feb 17, 2011 at 5:28 PM, Andrei Alexandrescu <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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/phobos/attachments/20110217/77b379d6/attachment.html>
More information about the phobos
mailing list