Re: [whatwg/streams] Examine interaction of resizable array buffers with Streams (Issue #1248)

I haven't investigated this deeply, but regarding the discussion at https://github.com/tc39/proposal-resizablearraybuffer/issues/111#issuecomment-1324343989, I wonder if it might actually be possible to take advantage of resizable buffers in the streams API to make it more pleasant to use? That is, are there technically-backward-incompatible, but probably-real-world-compatible changes we could make, that would let us stop creating so many different ArrayBuffers?

I guess userland streams are the real crux. @syg, is there any way to get this behavior, using spec/implementation primitives introduced by the resizable buffers proposal? (Not necessarily restricted to public JavaScript APIs.)

```js
const ab1 = constructAB();

const ab2 = transferMemoryFrom(ab1);
// at this point ab1 must act as if it's transferred

// ... now developer code manipulates the contents of ab2 ...

switchMemoryBackToAB1();
// at this point ab2 must act as if it's transferred,
// and ab1 must reflect any modifications that were made to the backing memory.
```

---

The other area I wonder about, is whether we could/should use the resizable buffers primitives to replace our practice of vending smaller ArrayBufferViews onto the backing ArrayBuffer, to reflect how many bytes we used. Probably not, but maybe worth some thoughts...

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/streams/issues/1248#issuecomment-1324644623
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/streams/issues/1248/1324644623@github.com>