Transience of .front in input vs. forward ranges

[H. S. Teoh]

On Sun, Nov 04, 2012 at 07:11:22PM -0800, Jonathan M Davis wrote:
> 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.
[...]

The crux of what deadalnix proposed is that range transformers simply
pass .transient along, whilst range consumers decide whether or not to
use .transient. So this isn't even an issue until you are in a range
consumer, which can decide whether or not the transient range should be
used.

IOW, the choice between .transient or not isn't even made until the end.
The range consumer is the one in the position to decide whether or not
.transient should be used.


T

-- 
A bend in the road is not the end of the road unless you fail to make the turn. -- Brian White