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
