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

[H. S. Teoh]

On Mon, Dec 23, 2013 at 03:30:12PM +0000, Francesco Cattoglio wrote:
> On Monday, 23 December 2013 at 15:23:45 UTC, bearophile wrote:
> >If the new iota accepts new types, then no existing code is using
> >iota for such cases. So you are not breaking code is you offer a
> >more restricted range for such types, avoiding O(n) behavior for
> >them.
> 
> I do realize this, but I don't really like having iota() returning
> different ranges for different types. Do you think this would make
> sense?
> Something like "iota returns a RA range for arithmetical types and a
> ForwardRange for any other type supporting opUnary!++"?

I think this is OK. It's just like map() returning an input range if you
give it an input range, a forward range if you give it a forward range,
etc.. Or joiner() returning a forward range only if you give it a
forward range of a forward range, otherwise it's just an input range,
even if one of the inner / outer ranges is forward (both the outer and
inner range must be forward ranges, otherwise the result can't guarantee
that .save will work correctly).

Basically, return the best range you can without adding hidden costs
(like O(n) methods), otherwise fall back to a more primitive range type.
This rule is observed by other parts of Phobos too.


T


-- 
The richest man is not he who has the most, but he who needs the least.