Transience of .front in input vs. forward ranges

[Andrei Alexandrescu]

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.

> If we're going to support transient fronts, then we need a solid plan for
> doing so. Even if it's the case that we're ultimately going to go with input
> ranges' fronts being considered transient, and all other ranges' fronts being
> considered non-transient, we need that to be clear and be made explicitly
> clear in the docs. It's definitely not how things are treated right now.

I think indeed input ranges should offer no more guarantees about the 
transiency of their .front as any other APIs offering the same type. 
Invoking .popFront for an input range means the current element buffered 
is discarded and replaced with the next one.

Requiring anything more would put undue pressure on any actual input 
range implementations and would essentially make the entire range 
infrastructure unusable efficiently with streaming.

For ByLine we should add another range that automatically produces 
strings - either ByLineStrings or ByLine!string.


Andrei