Thank you everyone for the feedback. I made the wrong assumption
about phobos design, I didn't knew that the policy here is "when
needed, relax the range", and now I see it makes perfect sense.
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).
On Tuesday, 24 December 2013 at 01:42:21 UTC, H. S. Teoh wrote:
there's
an overload (or multiple overloads?) specifically for
floating-point
types, and you'll have to take into account the quirks of
floating-point
types to handle all the cases correctly.
[...] You might want to keep the floating-point
overload(s) of iota as-is to avoid having to deal with this
mess. :)
I actually think the current float doesn't behave perfectly
either. I will not forget about float quirks, don't worry.
Ah, nice. There's an unstated assumption here - adding inc n
times is the same as adding n * inc.
Right, completely missed that. I guess checking a few test cases
at compile time is the best one can do. Checking for every n
could take some infinite amount of time :P
No, there are types for which increment is sensible but not
adding an arbitrary number.
I agree. After relaxing the range, we can prefer a specialized
version over the iota(begin, end, 1) version. The latter should
be used as a backup instead for cases where ++ is not implemented.
Not sure I understand this, but any reasoning that leads to the
conclusion that simple ++ ranges should be discarded must be
carefully revised.
Maybe I should have pasted all the suggestions from h.s. teoh, to
make it more clear which one I didn't like.
He suggested to add extra functionality if the type provides
opUnary!--.
++ ranges will be supported. what will not be supported is extra
functionality if -- is defined, because similar types used in the
same case might produce different results.
