Transience of .front in input vs. forward ranges

[Andrei Alexandrescu]

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). 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 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.


Andrei