I would rather expect that the limit would restrict size of the
result space and that the iterator could be used to freely move
inside that limited space while allowing to call get() as often
as one likes. So the limit should in my opinion rather be imposed
on the move operations than on the get operations.
WDYT?
TZ: that makes sense
I believe this change is defendable in a feature-level release because
- the behavior of shift is quite odd to start with (and IMHO should also
be adjusted in other cases)
- I would not expect much if any code to actually rely on the shift
operator with a negative index
WDYT?
TZ: AFAIK we are not using any shift operations in our code, so no objections
from this side.
-Torsten
