Tricky semantics of ranges & potentially numerous Phobos bugs

[H. S. Teoh]

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