Transience of .front in input vs. forward ranges

[deadalnix]

Le 06/11/2012 07:49, Andrei Alexandrescu a écrit :
> On 11/6/12 4:36 AM, H. S. Teoh wrote:
>> Hmm. Another idea just occurred to me. The basic problem here is that we
>> are conflating two kinds of values, transient and persistent, under a
>> single name .front. What if we explicitly name them? Say, .copyFront for
>> the non-transient value and .refFront for the transient value (the
>> names are unimportant right now, let's consider the semantics of it).
>
> We could transfer that matter to the type of .front itself, i.e. define
> a function copy(x) that returns e.g. x for for string and x.dup for
> char[] etc. There would be problems on e.g. defining copy for structs
> with pointer and class reference fields etc.
>
> One quite simple approach would be to define (on the contrary)
> .peekFront, which means "yeah, I'd like to take a peek at the front but
> I don't plan to store it anywhere". That would entail we define eachLine
> etc. to return string from .front and char[] from .peekFront, and
> deprecate byLine.
>

This have the same issue than .transient have in regard of transformer 
ranges (BTW what is the correct terminology for that ?).