Transient ranges

[Steven Schveighoffer via Digitalmars-d]

On 5/30/16 8:44 AM, Andrei Alexandrescu wrote:
> On 05/30/2016 08:21 AM, Joseph Rushton Wakeling wrote:
>> On Sunday, 29 May 2016 at 17:29:35 UTC, Steven Schveighoffer wrote:
>>> This doesn't help at all. I can still make a "transient" range with
>>> all three range primitives.
>>>
>>> There seems to be a misunderstanding about what a transient range is.
>>>
>>> byLine is a transient range that requires the front element be
>>> cacheable (I have to build the line somewhere, and reusing that buffer
>>> provides performance). Shoehorning into a popFront-only style "range"
>>> does not solve the problem. Not only that, but now I would have to
>>> cache BOTH the front element and the next one.
>>
>> Ack, yea, I think see the issue.  It's
>>
>>      auto a = transientRange.front;
>>      transientRange.popFront() // <=== now a has changed
>>
>> Even if you go with the only-2-primitives one, you'd have the same
>> problem:
>>
>>      auto a = transientRange.front;
>>      auto b = transientRange.front;   // <=== now a has changed
>
> That's right. The one approach that works here is to acknowledge the
> range has no buffering at all and require the user to provide the buffer
> as an argument. However, that would make for a different primitive that
> does not fit within the range hierarchy. -- Andrei
>

Yes, this is how e.g. Linux getline works. But this leaks even more 
implementation details to the user, and still doesn't solve the problem, 
it just pushes it onto the user.

It also would make for some awkward pipelining.

Another solution is to accept a "buffer manager" that is responsible for 
determining how to handle the buffering.

-Steve