Tricky semantics of ranges & potentially numerous Phobos bugs

H. S. Teoh hsteoh at quickfur.ath.cx
Wed Oct 17 09:39:24 PDT 2012


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.

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

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.


T

-- 
They pretend to pay us, and we pretend to work. -- Russian saying


More information about the Digitalmars-d mailing list