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
