Transience of .front in input vs. forward ranges

[deadalnix]

Le 05/11/2012 04:11, Jonathan M Davis a écrit :
> On Sunday, November 04, 2012 15:40:18 deadalnix wrote:
>> Le 04/11/2012 03:26, Jonathan M Davis a écrit :
>>> 3. Make it so that ranges which can be transient are non-transient by
>>> default but provide a function to get at a transient version for speed
>>> (which was the fastRange proposal in this thread). The main problem here
>>> is that when the fast range gets wrapped, it's transient, and so anything
>>> using the wrapped range will be forced to use the transient version
>>> rather than using the non- transient version and only using the transient
>>> version when it's asked for. So, I don't think that this is particularly
>>> viable.
>>
>> Can you elaborate on that. I definitively don't see a problem that big here.
>
> The problem is that you can't opt out of the fast range once you've got it. If
> you use fastRange and then the result ends up getting wrapped by another
> range, that range's front is transient and has no way of indicating it. So,
> you're right back in the boat that we're in right now. In order to avoid that,
> virtually all range-based functions would have to not use fastRange, because
> they have no idea whether you're going to use their result to pass to another
> function or not.
>
> - Jonathan M Davis

HS Teoh explained it nicely.

The responsibility of using .transient or not belong to the consumer. 
Only the consumer can know if a transient range is suitable.

So you don't wrap a transient range. You wrap a non transient range, 
and, if the consumer is able to handle the transcient version, it call 
.transient on its source, that call it on its source, etc . . . up to 
the real source.

If one transformer is unable to handle transient range, the it don't 
pass .transient to its source.