Ranges longer than size_t.max

[Stewart Gordon]

On 29/12/2012 21:13, Peter Alexander wrote:
> On Saturday, 29 December 2012 at 20:59:56 UTC, Stewart Gordon wrote:
<snip>
>> If we define a length that may overflow, then sooner or later some
>> code will be called on it that calls hasLength on the range, finds it
>> to be true, and then relies on length and malfunctions because the
>> value returned doesn't match the actual length.
>
> Using this logic, chain shouldn't have length either (it can overflow,
> as I demonstrated in the original post), but it does, and it should.
> There are many ranges in Phobos that may overflow in length.

Yes, you have a point there.  Any facility for creating a range by 
combining ranges is liable to overflow if it defines a length property. 
  But I would expect that in practice 99% of finite ranges would be 
nowhere near 2^64 in size, so an overflow would be an exceptional case.

> The problem with permutations is that, for the kinds of permutations you
> are likely to use often, length will not overflow. It would be really
> useful to have length available when this is the case.

Maybe the solution is to define two permutation range classes: one with 
length that asserts that the number of elements <= 20, and one without 
length that places no bound.

If the set size is a template parameter rather than being set at run 
time, then it can define length conditionally.

Stewart.