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.
