On Wed, Oct 17, 2012 at 12:55:56PM -0700, Jonathan M Davis wrote:
[...]
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.
It's perfectly possible to implement joiner, chain, find, count, cmp,
equal, until, filter, map, reduce, without assuming that the value
returned by .front is persistent. Just to name a few. In fact, it's even
possible to implement cartesianProduct in which one of the ranges is an
input range. I'd hardly call that useless.
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.
The motivating example for input ranges, at least according to TDPL, is
find(). There's nothing about find() that precludes non-forward input
ranges. A lot would be missing from the usefulness of ranges if we were
forced to only use forward ranges.
[...]
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.
I can think of quite a few situations in which it's useful to not assume
that the return value of .front is persistent, which I've already
mentioned before: in-place array permutation, reused buffers for complex
computations, etc..
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.
[...]
I think I'm not so sure about Andrei's lumping input ranges with
persistent return values from .front together with forward ranges. Some
algorithms, like findAdjacent, do not need a forward range, but they do
need a persistent .front. I do not like the idea of artificially
limiting the scope of findAdjacent just because you can't assume input
ranges' .front returns a persistent value. Like somebody else mentioned,
whether .front is transient or not is orthogonal to whether the range is
an input range or a forward range. There can be ranges whose .front is
persistent, but they can't be forward ranges for practical reasons.
