Re: [streams] Support reading bytes into buffers allocated by user code on platforms where only async read is available (#253)

> Agreed. I thought you prefer not returning something structured, so suggested the empty view holding the detached buffer.

I think { value, done } might be awkward but it does have advantages. I am finishing up my "anti-async-read()" post which talks about the disadvantages of EOS a decent bit (including this new point). One thing in favor of { value, done } is that it is the same interface used by ES6 iterators, and possibly will be reused by ES7 async iterators. But without syntax support (like `for-of` for ES6 iterators) it is kind of a pain. More soon.

> The question is whether the common read(undefined) user should be prepared to see { someValue, true } or not.

Good analysis in general. On this particular point, my initial intuition is that they should not expect that. Most consumers (both read(view) and read(undefined)) will ignore value if done is true. Byte streams do give you back a `value` just in case you need it. But the general semantics is that if `done` is true then `value` should not be paid attention to.

I will think on this a bit more though.

---
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/streams/issues/253#issuecomment-77460599