Tricky semantics of ranges & potentially numerous Phobos bugs

[Don Clugston]

On 17/10/12 23:41, H. S. Teoh wrote:
> 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.

Is it actually orthogonal? Is it possible for a forward range to be 
transient?

Or is it an intermediate concept?
TransientInputRange -> NonTransientInputRange -> ForwardRange