Transience of .front in input vs. forward ranges

[deadalnix]

Le 02/11/2012 21:17, Jonathan M Davis a écrit :
> 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.
>
> - Jonathan M Davis

The whole point of my proposal is to avoid adding isTransient or 
something similar.

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 .
3/ Range that don't support that feature can be made compatible with 
UFCS, .fast being a NOP in such case.
4/ Ranges that work as a transofmration on existing ranges can propose 
the property too if they don't require .front to be persistant. It is 
implemented by bubbling the property call to the source range.
5/ It is up to the ultimate consumer to call that property or not.