Transience of .front in input vs. forward ranges

[H. S. Teoh]

On Fri, Nov 02, 2012 at 04:17:10PM -0400, Jonathan M Davis wrote:
> On Friday, November 02, 2012 10:01:55 H. S. Teoh wrote:
> > Ah, I see. That makes sense. So basically it's not the source (or
> > any intermediate step) that decides whether to use the optimization,
> > but the final consumer.
> > 
> > Though now we have the issue that all intermediate ranges must
> > propagate .fast, which is troublesome if every range has to do it
> > manually. Can this be handled automatically by UFCS?
> 
> It's no different form propogating slicing or random access or
> whatnot. Wrapper ranges have to look at the capabilities of the ranges
> that they're wrapping and create wrappers for each of the range
> functions where appropriate. If we added isTransient or fastRange or
> whatever, wrapper ranges would then have to take it into account, or
> the wrapper wouldn't have it.
[...]

I wish Andrei would give some input as to how we should proceed with
this. I do consider this a major issue with ranges, because for
efficiency reasons I often write ranges that have transient .front
values, and they can lead to subtle bugs with the current implementation
of std.algorithm. It would be good to settle on this issue one way or
another. I'd be happy even if the decision is to say that transient
ranges are invalid and shouldn't be considered "real" ranges. Anything
is better than the current nebulous state of things which only leads to
subtle bugs for the unwary.


T

-- 
Real Programmers use "cat > a.out".