Transience of .front in input vs. forward ranges

[deadalnix]

Le 07/11/2012 22:40, Jonathan M Davis a écrit :
> On Wednesday, November 07, 2012 21:31:13 deadalnix wrote:
>> OK, overall, .peekFront seems like a good idea. Something I'm afraid
>> with .peekFront is code duplication.
>>
>> Let's take the joiner example. Joiner's transientness depend on its
>> source transientness. This seems to me like a very common case for
>> transformer ranges. If we choose the .peekFront, the naive thing to do
>> is to implement the same algorithm twice, using front and peekFront,
>> which is code duplication, and usually a bad idea.
>
> Why would you need to duplicate anything?. If you can implement it using
> peekFront, then you use peekFront. If you can't, you use front. And anything
> which uses front when you could have used peekFront will still work. Also, if
> a free function peekFront which forwards to front is defined, then all range-
> based functions can use peekFront if they need it regardless of whether a
> range defines it (it's just that it would do the same as front in the case
> where the range didn't define it).
>
> - Jonathan M Davis

OK, seeing your answer and H. S Teoh, I think I badly expressed myself, 
because none of you understood. Let's try to explain it better.

So back on our joiner range. This range have a source, and will be given 
to a consumer as follow :
source -> joiner -> consumer .

Now let's consider that source provide its own, transient peekFront. Now 
joiner can provide both peekFront (based on source.peekFront), which is 
transcient and front (based on source.front) which is not transcient.

The fact is that both front and peekFront in joiner will have the same 
implementation, because the transience of joiner depends of the 
transience of its source (like most tranformer ranges).

Or, with sample code :

struct Joiner {
     R source;
     // Fields and range stuffs.

     @property front() {
         // Some computation using source.front
     }

     @property peekFront() {
         // Exact same computation using source.peekFront
     }
}

I hope this make the code duplication more apparent.

It is impossible for joiner to provide only a version with peekFront, 
because joiner.front will be transient, and if it doesn't provide the 
version with .peekFront, it can't take advantage of the improvement that 
transience can provide.

So my question is, how this duplication can be avoided ? If it can, 
.peekFront is definitively the way to go. But if it can't, this seems 
like a really problematic point.