Tricky semantics of ranges & potentially numerous Phobos bugs

Jonathan M Davis jmdavisProg at gmx.com
Wed Oct 17 12:55:56 PDT 2012


On Wednesday, October 17, 2012 13:15:12 Andrei Alexandrescu wrote:
> On 10/16/12 3:07 PM, H. S. Teoh wrote:
> > Perhaps mark ranges with an .isTransient property
> 
> isTransient!R is exactly the same thing as isInputRange!R &&
> !isForwardRange!R.

In what way? There is nothing anywhere that states that an input range's front 
could be invalidated upon a call to popFront. There's nothing inherent in the 
fact that range can't be saved that makes it so that front must be invalidated 
upon a call to popFront. You could easily define an input range of bytes over a 
file where front is perfectly valid after a call to popFront, because it's a 
value type. You could also define ByLine so that its front is perfectly valid 
after a call to popFront. It's just that it requires that a new buffer be 
allocated instead of reusing the buffer. That has nothing to do with the fact 
that its incapable of copying its state such that you could have multiple 
copies of it being iterated over separately. I don't see anything in the 
concept or definition of input ranges which implies that front would be 
invalidated by a call to popFront.

I'm increasingly convinced that input ranges which are not forward ranges are 
useless for pretty much anything other than foreach. Far too much requires 
that you be able to save the current state - and most stuff _inherently_ 
requires it such that it's not simply a question of implementing the function 
differently. And adding even further restrictions on input ranges just makes it 
worse. It actually wouldn't hurt my feelings one whit if we got rid of the 
idea of input ranges entirely. It's perfectly possible to implement ranges 
like ByLine as forward ranges. It just requires a bit more work. But they'd be 
_way_ more useful if they were. In my experience the only time that you don't 
need to dup what ByLine or ByChunk gives you is when all you need is foreach, 
and if that's really the case, then opApply can be used for foreach, and 
ByLine and ByChunk can be defined in ways that actually allow them to not only 
not invalidate the result of previous front calls but to actually be full-on 
forward ranges, making them actually useful for things beyond foreach.

Regardless, there's nothing in how input ranges are currently defined which 
indicates that front would ever be invalidated for _any_ type of range, and 
ByLine and ByChunk are pretty much the only ranges I've ever seen which 
invalidate previous calls to front. So, I don't see how you could think that 
they're anything but abnormal. And if you really want to argue that whether 
front can be invalidated or not is somehow part of the difference between an 
input range and a forward range, then the documentation on that needs to make 
that _very_ clear, and it's going to be that much worse to deal with input 
ranges which aren't forward ranges.

- Jonathan M Davis


More information about the Digitalmars-d mailing list