Tricky semantics of ranges & potentially numerous Phobos bugs

[H. S. Teoh]

On Wed, Oct 17, 2012 at 12:39:13PM -0400, Andrei Alexandrescu wrote:
> On 10/16/12 1:28 PM, Jonathan M Davis wrote:
> >So, it's fine that ByLine is a range as long as we're willing to put
> >up with it not working with a lot of range-based functions because of
> >its abnormal behavior. But I don't think that it's at all reasonable
> >for range-based functions in general to not be able to rely on front
> >returning the same type every time or on its value disappearing or
> >becoming invalid in some way after a call to popFront. That's
> >completely untenable IMHO.
> 
> Then what is to you the difference between an input range and a
> forward range?
[...]

So what you're saying, is that we cannot rely on the value of .front
after popFront() is called, and that the only way to ensure the validity
of .front is to use a forward range's .save, and access the saved copy's
.front?

It makes sense to me, but then we'd need to revise quite a lot of code
in Phobos, as I've seen quite a number of places where .front is cached
in some local variable or struct field, which would be invalid by your
definition.


T

-- 
This is not a sentence.