On Wednesday, 17 October 2012 at 19:14:12 UTC, Jonathan M Davis
wrote:
On Wednesday, October 17, 2012 12:39:13 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?
Whether you can get a copy of the range. If you call save, you
can save its
current state and have two copies of the range to operate on
separately,
That's completely different from whether front can be kept
around or not. It's
perfectly possible to have an input range whose previous front
does not get
invalidated by a call to popFront. ByLine would be that way if
it allocated a
new buffer instead of reusing the old one. It just doesn't do
that because it's
less efficient to do so.
- Jonathan M Davis
This.
When you think about it, byLine *could* be a ForwardRange (it
could save its pget position in the file), allowing it to
backtrack, but that *still* wouldn't prevent it from overwriting
its own internal buffer on calls to front: That is just a detail
of its implementation.
A range's "Input-ness" or "Forward-ness" is completely orthogonal
from the returned front's transitiveness.
