"IndexType" for ranges

[Jonathan M Davis]

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