On 10/17/12 12:39 PM, H. S. Teoh wrote:
On Wed, Oct 17, 2012 at 12:22:55PM -0400, Andrei Alexandrescu wrote:
On 10/16/12 11:17 AM, H. S. Teoh wrote:
OTOH, if we clearly state that .front may not persist past the next
popFront(), then it would be up to the caller to .dup the return
value, or otherwise make a safe copy of it (or use the value before
calling popFront()).
The current ambiguous situation leads to one range doing one thing,
and another range doing something else, and either way, either this
code will break or that code will break.
Input ranges don't guarantee preservation of .front upon calling
.popFront. They do allow several to .front (without an intervening
call to .popFront) that should return the same result (i.e. a
one-element buffer).
[...]
This is contrary to what Jonathan has been saying. So which is it:
should .front return a persistent value, or a transient value that may
get invalidated by popFront? I have been assuming it's the latter, but
others have been saying it's the former.
The latter for input ranges, the former for anything stronger.
As Jonathan pointed out, some algorithms won't work with transient
.front values. I can think of one: findAdjacent, which requires that the
previous value of .front be preserved (otherwise you couldn't compare it
with the following element -- the template has no reliable way of saving
the previous value since we don't have a reliable way to deep-copy a
possibly complex data structure that might be getting overwritten by
popFront).
findAdjacent correctly restricts itself to work only with forward ranges.
Other algorithms, like joiner, currently don't work with transient
.front values, but can be made to work by tweaking the implementation.
People will hate me for saying this, but I think Phobos algorithms
*should* be written to work with minimal expectations, so I don't
consider it unreasonable to expect std.algorithm to work with transient
.front values where possible. (User code is a different matter, of
course). There *are* cases for which it can't work, which is why I
proposed the isTransient property, but people didn't seem to like that
idea.
No isTransient is needed.
Andrei
