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 ?).
