On Wednesday, 27 July 2016 at 06:18:07 UTC, Sönke Ludwig wrote:
> Am 26.07.2016 um 16:50 schrieb Johannes Pfau:
>> Am Mon, 25 Jul 2016 13:10:42 +0000
>>>
>>> Hello,
>>>
>>> I don't know if it is good practice or not, but sometimes it make
>>> life easier if you can put part of the data back into the input
>>> stream.
>>>
>>
>> Writing data back to a stream is quite uncommon. The standard way to
>> solve such problems is a peek method for buffered streams:
>>
>> auto buf = stream.peek(length)
>> // You can now look at the data in buf
>> stream.read() will still return the data read by peek, no need to write
>> data back into the stream.
>>
>
> With the notable exception of ungetc() for C's file streams. But working on the byte level is something that ranges should be used for in D's case and not streams, because the latter tend to have a high call overhead. So such a feature could make sense for a StreamInputRange/InputStreamRange wrapper.

Yes, and here is simple use-case for this: you have to process input stream of data chunks mixed with separators from the socket. To read only data and not separators, you can either ask stream code to "read until separator", or you can read as much as possible, then split on separator, return split-tail back to stream and process split-head. Now all your reads from stream will either start from the new data chunk or continue reading from it.

Of course, application code can manage all this on its own, but why not to help application programmer keep his code clean?