Ranges longer than size_t.max

[Jonathan M Davis]

On Saturday, December 29, 2012 02:18:36 Peter Alexander wrote:
> There was a discussion a while ago about the type returned by
> .length for ranges. I believe the conclusion was that it should
> always be size_t.
> 
> My question now is what to do with really large ranges? For
> example, if we have a range of permutations of the elements in a
> set, when the set is larger than 21 the number of permutations is
> 21 factorial, which is over 2^64. As far as I see, there are
> three options:
> 
> 1. Allow ranges to return BigInt for length.
> 2. Allow ranges like this but assert when .length overflows.
> 3. Allow ranges like this and just allow .length to overflow
> dangerously.
> 4. Do not allow ranges like this.
> 
> Option 1 solves the problem, but significantly complicates Phobos
> development for the rare case.
> 
> Option 2 works, and is practical, although runtime asserts are
> undesirable.
> 
> Option 3 is current Phobos practice (presumably because overflow
> is unlikely). See example below. This may be acceptable
> currently, but perhaps less so when overflow is more likely.
> --------------------------------
> auto a = iota(size_t.max / 2 + 1);
> auto b = chain(a, a);
> writeln(a.length); // 9223372036854775808
> writeln(b.length); // 0
> --------------------------------
> 
> Option 4 works, but it would be a shame to lose these ranges.
> 
> Thoughts?

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. Needing ranges of 
length greater than uint.max is definitely not the norm, and I would expect 
people caring that much about computational stuff to be using 64-bit anyway, 
since odds are they'll need the memory. Allowing for length to be anything 
other than size_t is extremely annoying for generic code.

- Jonathan M Davis