Transience of .front in input vs. forward ranges

deadalnix deadalnix at gmail.com
Mon Nov 5 07:35:30 PST 2012


Le 05/11/2012 04:47, Jonathan M Davis a écrit :
> 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

That is not true. As shown by sample code before the following happens :

Transient source ranges can be wrapped into the non transient one, using 
alias this and implementing only .front to dup. .transient then just 
unwrap. Code duplication is avoided most of the time.

Transformer ranges are usually transient or not according to their 
source. Joiner proposal by H. S. Teoh is done quickly, but in fact, you 
notice that joiner can have just one implementation, and that its 
transientness will depends on source transcientness. In this case, code 
duplication is avoided too.


More information about the Digitalmars-d mailing list