Tricky semantics of ranges & potentially numerous Phobos bugs

[monarch_dodra]

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.