Transience of .front in input vs. forward ranges

[deadalnix]

Le 05/11/2012 19:42, Jonathan M Davis a écrit :
> On Monday, November 05, 2012 15:48:41 deadalnix wrote:
>> 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.
>
> You still need to wrap it in every wrapper range which could possibly support
> transience. So, this affects every single range which could possibly support
> transience.
>

As shown before, most wrapper range wouldn't have to do a thing except 
rewraping with .transient . The typical situation is that a wrapper 
range get its transientness from the wraped range. So it boils down to 
womething like :

struct Wrapper(Wrapped) {
     Wrapped e;

     // Range implementation

     @property auto transient() {
         return Wrapper!(typeof(e.transient))(e.transient);
     }
}

Considering that doing a wrapper that is compatible with transient 
ranges is already some work and require the writer to be aware of such a 
concept (you can expect most programmer to simply ignore that fact).

The extra work for a wrapper range is really small, and add the benefice 
to ensure that the developer that programmed the wrapper took special 
care to ensure this will work with transient.

> At least with Andrei's proposal, transience is explicitly restricted to input
> ranges, which seriously reduces the problems caused by them, particularly
> since so few functions can really function with just an input range.
>

This proposal is simplistic. array() is not even implementable with such 
an approach. It is also slower for several use cases shown in this thread.

And finally, it is likely that many non transient compatible stuff will 
proliferate, leading to undefined behavior all over the place.

Simply telling to people to follow some guideline is not going to work. 
Many lead devs have experienced that with small teams, and we are 
talking here about every single D user.