Transience of .front in input vs. forward ranges

[Jonathan M Davis]

On Sunday, November 04, 2012 19:41:39 H. S. Teoh wrote:
> 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.

And how on earth would it decide that when it's been wrapped by who-knows how 
many wrapper ranges? It would be far too late at that point. Unless you expect 
that every one of those ranges is going to duplicate itself such that when you 
call fastRange or transient or whatever you can get a different range type 
which is transient? That's worse than inTransient IMHO. The only advantage 
that it has is that if you fail to take it into account, you end up with the 
non-transient range, and your code doesn't end up doing crazy stuff. But in 
either case, all of the range types have to take it into account, complicating 
their implementations that much further, and fastRange would complicate those 
implementations far more than isTransient would, because it would require code 
duplication rather than just statically disallowing the transient range when 
it wouldn't work.

- Jonathan M Davis