Transience of .front in input vs. forward ranges

Jonathan M Davis jmdavisProg at gmx.com
Sun Nov 4 19:11:22 PST 2012


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


More information about the Digitalmars-d mailing list