Re: [streams] [WIP] Putting a chunk back in the readable stream queue (#275)

I'm not insisting on peek().  I just think it might be cleaner than trying to implement an `unshift` operation (particularly given the stream closed state).

I think I agree with your statement that a way to read a precise number of bytes (readInto+amountReadable) is sufficient for ReadableByteStream.  Most byte-stream algorithms will work just fine with this since its how bsd socket streams, etc, work today.

I just dislike the `unshift` for ReadableStream.  My reasoning goes something like this: (Sorry for stream of consciousness list... still early for me...)

1) "normal" stream mutation is putting things on the front and taking them off the back.
2) For ReadableStream it seems the "chunks" are effectively opaque types to the stream.
3) Reading just a few bytes from a ReadableStream chunk and then putting the remainder back is effectively mutating the last chunk in the ReadableStream.  To me this is "not normal" mutation for the stream.  The script could put back anything in that last chunk; even a completely different type.
4) Using peek() avoids allowing this non-normal mutation.  If the client code wants to do sub-chunk splitting, it can do that itself.
5) Lets not contort the ReadableStream API for an algorithm that's really byte-based, not chunk-based.

So what about removing our version of `unshift` and adding `peek()` just for the ReadableStream?  ReadableByteStream would not have either of these methods.

Of course we could also survey npm packages to see how often their stream `unshift` is used.  If its particularly popular, maybe we keep it in with the caveat it can fail if the stream closes on the last read.

---
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/streams/pull/275#issuecomment-73524466