Tricky semantics of ranges & potentially numerous Phobos bugs

[Andrei Alexandrescu]

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