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.

Reply via email to