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.
