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. T -- Having a smoking section in a restaurant is like having a peeing section in a swimming pool. -- Edward Burr