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

[Francesco Cattoglio]

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.