Transient ranges

[Alex Parrill via Digitalmars-d]

On Monday, 30 May 2016 at 12:53:07 UTC, Steven Schveighoffer 
wrote:
> On 5/30/16 5:35 AM, Dicebot wrote:
>> On Sunday, 29 May 2016 at 17:25:47 UTC, Steven Schveighoffer 
>> wrote:
>>> What problems are solvable only by not caching the front 
>>> element? I
>>> can't think of any.
>>
>> As far as I know, currently it is done mostly for performance 
>> reasons -
>> if result is fitting in the register there is no need to 
>> allocate stack
>> space for the cache, or something like that. One of most 
>> annoying
>> examples is map which calls lambda on each `front` call :
>> https://github.com/dlang/phobos/blob/master/std/algorithm/iteration.d#L587-L590
>
> Maybe my understanding of your post is incorrect. You said "It 
> is impossible to correctly define input range without caching 
> front which may not be always possible and may have negative 
> performance impact."
>
> I'm trying to figure out which cases caching makes the solution 
> impossible.

One case is wrapping a network stream: a TCP input range that 
yields ubyte[] chunks of data as they are read from the socket, a 
joiner to join the blocks together, a map that converts the bytes 
to characters, and take to consume each message.

The issue is that, in a naive implementation, creating the TCP 
range requires reading a chunk from the socket to populate front. 
Since I usually set up my stream objects, before using them, the 
receiver range will try to receive a chunk, but I haven't sent a 
request to the server yet, so it would block indefinitely.

Same issue with popFront: I need to pop the bytes I've already 
used for the previous request, but calling popFront would mean 
waiting for the response for the next request which I haven't 
sent out yet.

The solution I used was to delay actually receiving the chunk 
until front was called, which complicates the implementation a 
bit.