Transience of .front in input vs. forward ranges

[deadalnix]

Le 04/11/2012 14:55, Andrei Alexandrescu a écrit :
> 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.
>

You are explaining here that is reasonable to expect so, not that this 
is the most obvious choice, the most simple, or whatever.

The conclusion exceed the argument here.

I'd also argue that if people that wrote phobos get that wrong (I think 
it is fair to consider people writing phobos code as D specialists), it 
is safe to assume that most D programmer will get it wrong.

>> 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.
>

This is already doomed to phobos implementation of range stuffs. That 
may sound nice on paper, but practice have shown this isn't a realistic 
approach.

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

If we are modifying things like that, better proposal have been made in 
this thread and previous.