Ranges longer than size_t.max

[Jonathan M Davis]

On Saturday, December 29, 2012 07:12:49 Mehrdad wrote:
> On Saturday, 29 December 2012 at 02:14:22 UTC, Jonathan M Davis
> 
> wrote:
> > I'd be very strongly inclined to go with #4 and just say that
> > anyone who actually cares about numbers that large should use
> > 64-bit.
> 
> Uhm, 64-bit?
> 
> What about large files (> 4 GiB) on 32-bit systems?
> 
> (Say, if a range wants to provide random access to the bytes of
> an 8 GiB file?)

You bring up a good point, but not even arrays support that, so stuff like 
std.mmfile can't possibly work with large files on 32-bit systems, not with the 
current design anyway (as it gives you an array to operate on). It may be that 
you just need to do something different if you want to operate on large files on 
32-bit systems. I don't know.

Plenty of stuff right now in Phobos isn't going to work right now if you try 
and have a length of 64 bits on a 32-bit system. size_t is used pretty much 
everywhere. And it's going to make generic code a _lot_ less pleasant if we 
have to worry about using anything other than size_t. It's already been 
causing us problems that iota does, and we've discussed making it so that it 
doesn't. But even if we allow ulong for length and indexing on 32-bit systems, 
that's a completely different ball game from permitting BigInt.

So, I'd _very_ much like to always restruct length and indices to size_t for 
ranges. It will make all of the generic handling of that stuff far more 
pleasant. But we may very well be forced to permit ulong on 32-bit systems due 
to practical concerns such as large file handling on 32-bit systems.

Oh, how I wish that 32-bit systems would just die out. It would make so many 
things so much easier. No such luck on that yet though, much as most PC 
processors are 64-bit now.

- Jonathan M Davis