Transience of .front in input vs. forward ranges

[Jonathan M Davis]

On Sunday, November 04, 2012 08:55:48 Andrei Alexandrescu wrote:
> On 11/3/12 9:02 PM, Jonathan M Davis wrote:
> > Andrei seems to think that algorithms should consider input ranges' fronts
> > to be transient, and that forward ranges and greater shouldn't have
> > transient fronts. And I don't think that he's said much about it after
> > that (probably mostly because he was out of town and unable to
> > communicate on the newsgroup much for a while). However, I think that
> > he's the only one in this thread who had come to that conclusion. Most of
> > the rest of us agree that transience isn't necessarily related to the
> > type of range at all. And I think that most everyone has considered
> > ranges like ByLine and ByChunk to be bizarre and abnormal and not
> > something that normal algorithms need to worry about (and if anything
> > that ByLine and ByChunk should be changed to be non-transient or to not
> > be ranges at all).
> 
> (Let's drop the argumentum ad populum part and focus on the technical
> argument.)
> 
> These ranges are the only ones dealing with streaming input - the only
> veritable input ranges, so qualifying them as bizarre would pretty much
> raise the point that input ranges are bizarre.
> 
> An input range means that you're fetching an item, looking at it, and
> discard it. Transience is, in my opinion, quite intrinsic to input
> ranges. It is also a well understood fact that copying a char[] does not
> guarantee its contents are copied, in any API. So just by seeing as
> ByLine is an input range of char[], its properties are self-evident. If
> it were an input range of string, it would have other properties,
> equally self-evident. This destroys the argument that transience is
> unrelated to the range type and kind.

There is nothing inherent to an input range that requires that front be 
transient. Ranges like ByLine can work just fine with non-transient fronts. 
They're just less efficient that way. And as H. S. Teoh has pointed out, you can 
easily have forward ranges with transient fronts. So, whether you can save a 
range really doesn't have much to do with whether front can be non-transient 
or not.

Now, if we say that we need transient fronts for some input ranges but don't 
want to add an isTransient trait or something similar, and so we're going to 
say that transient fronts are only acceptable for input ranges and that 
algorithms have to assume that front can be transient for input ranges, then 
fine. I don't really like it, but I'm definitely in favor of simplifying things 
here.

However, that means that we need to be very clear about the fact that input 
ranges can have transient fronts and that algorithms cannot assume that their 
fronts are not transient (something that only you appear to have thought was 
clear). We then either have to change a bunch of algorithms so that they 
require forward ranges, or we need to create a trait which can determine 
whether front is transient in it least some cases (it would still be claiming 
that front is transient in some cases where it isn't, because it can't know 
for sure, but we'd at least be able to figure it out in some cases), and make 
algorithms use that in their constraints when they deal with input ranges. 
std.array.array would be a prime case where an algorithm would have to be 
changed, because it can't function with a transient front, and it's a prime 
example of a function that you'd normally expect to work with an input range. 
And this _will_ break code. It'll allow us to fix the ByLine problem though.

- Jonathan M Davis