Transience of .front in input vs. forward ranges

[deadalnix]

Le 04/11/2012 16:16, Andrei Alexandrescu a écrit :
> On 11/4/12 9:36 AM, deadalnix wrote:
>> Let's put back relevant elements of the solution I propose :
>> 1/ range preserve .front by default .
>> 2/ Ranges that would get performance boost from invalidating .front can
>> propose a property (we called it .fast in the thread) that return a new
>> range that invalidate .front .
>
> IMHO this property is deducible from the others:
>
> fast!R == isInputRange!R && !isForwardRange!R &&
> hasMutableIndirections!(ElementType!R)
>
> I think it would be vastly better to avoid defining a new property of
> ranges (that subsequently would need to be cross-checked by many
> algorithms).

You can stop here. This shows that you didn't understood the proposal.

The whole point of the proposal is to avoid the cross checking part. See 
code sample posted earlier in the discussion for full understanding.

> Then we have additional scalability issues because all
> derived ranges would need to propagate .fast etc. Then we need to cater
> for odd cases such as random-access ranges being .fast.
>

The beauty of the proposal is that nothing NEED to be .fast .

> The simpler way would be to simply state that input ranges can't
> guarantee the persistence of .front after calling .popFront. This is
> quite expected for input ranges, and no different for any object that
> gives a char[]-based API; subsequently changing the object may change
> the contents of the char[] returned.
>
> The algorithms that need to worry about .front's transience are only the
> ones that work with input ranges (as opposed to forward ranges or
> stronger). This approach puts the burden in the right place - on the
> implementers of specific algorithms supporting one-pass streaming.
>