[phobos] std.array.ilength

[David Simcha]

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.

On 2/17/2011 6:00 PM, Andrei Alexandrescu wrote:
> 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
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos
>