std.range.iota enhancement: supporting more types (AKA issue 10762)

[Francesco Cattoglio]

On Tuesday, 24 December 2013 at 11:05:05 UTC, Jakob Ovrum wrote:
> On Tuesday, 24 December 2013 at 10:38:17 UTC, Francesco 
> Cattoglio wrote:
>> The range will only be a RA range for types that implement 
>> (inc * n) and ((end - begin) / step) (used for lenght 
>> computation), otherwise it will be a ForwardRange, because it 
>> can't be directional if we can't compute the last element in 
>> O(1).
>
> Bidirectionality and random access are separate capabilities; 
> the former can be supported without the latter through `--end`, 
> and `end == start`, and we should support that. If it causes 
> problems when the same range is traversed from both ends, then 
> that is an issue with the UDT's operator overloads.

There's a catch: if we want bidirectional, we need the last 
element of the range. This means we have to choose one of the 
following 2:
1) make the assumption that the user choose an end that 
corresponds to the first element out of the range.
2) compute the last item by ourselves.

1) would be error prone: if the user fails to provide a correct 
entry, popping the back would give you values that differ from 
the ones you pop from the front. The user might also genuinely 
not know what the last element is (eg: you add 25 minutes to a 
given time, and you want the range to stop before midnight).
2) is not possible in O(1), unless we can divide by the step.

We could provide bidirectionality if the type supports division 
but not multiplication. But I honestly can not see any use case 
for this. Unless I'm missing something that allows quick 
computation of the end using only += and comparison.