Transience of .front in input vs. forward ranges

[Andrei Alexandrescu]

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.


Andrei