On Tuesday, October 02, 2012 20:45:36 David Nadlinger wrote: > On Tuesday, 2 October 2012 at 17:24:32 UTC, Andrei Alexandrescu > > wrote: > > Yes. Unfortunately there are few, few cases in which size_t is > > insufficient (e.g. an input range from a file or a large iota, > > both on 32-bit builds). I personally think these are too few to > > need formal support. > > I'd throw bit arrays into the mix, where 32 bit can also be quite > small. There might also be some other clever hacks using custom > index types for representing non-linear data structures as ranges. > > The question is whether such ranges are likely to be used as > random access ranges. I can't come up with a compelling use case > right now, but I'd rather think twice before throwing support for > them out of the window and later regretting it. Also, one of the > simplest ranges (iota) not fitting the range concept has somewhat > of an odd aftertaste.
If it were restricted to size_t, it would just mean that those types would be restricted to 32-bits for their length and index on 32-bit machines if you would want them to function as ranges (as iota would - if size_t is required, then it's going to use size_t, not become incompatible as a range). But it's types like this which muddy things a bit. Ideally, we'd insist that all ranges use size_t. It simplifies things and certainly using smaller than that doesn't really make sense. But if we really need to support ulong, then unfortunately, we really need to support ulong - in which case presumably length and indices would have to be size_t or ulong (either that or IndexType.sizeof >= size_t.sizeof, but allowing signed types also complicates things in nasty ways). It _would_ be great to be able to just insist on size_t though. The question is whether we can reasonably get away with that. - Jonathan M Davis