Ok to summarize:

For CoW, you'd do: writer.write(ab); with async write (ab) { const copy = ab.slice(0); try { await doWrite(copy); } finally { copy.detach() } }

For explicit take you'd have to do something like: write.write(ab.getTaker()) with async write (taker) { const [ab, release] = taker(); try { await doWrite(ab); } finally { release(); } }

taker() could only be called once (throws after) and returns both the ab and a release function, which once called restore the state of the original array buffer instance. I guess we could imagine different modes for the taker. For example readonly would yield a readonly buffer and put the original buffer in read-only mode, which means they could be the same object. A write mode would yield a mutable buffer, putting the original buffer in read-only mode?

There's always the risk that the receiver to which you provide the taker will never call release.

Streams would definitely use that. Right now users have to do

const { value: newUint8Array } = reader.read(inputUint8Array);

where newUint8Array.buffer !== inputUint8Array.buffer but they point to the same backing memory. If people didn't have to juggle multiple variables for the same backing memory, that would be nicer.

I definitely like the idea of this API. I think I'd prefer to generalize it a bit so it's not tied specifically to ArrayBuffer/ArrayBuffer views only. If a generic concept of a "transferable" object were introduced to in the language (of which only ArrayBuffer and TypedArrays would initially be included), then this taker api would work with any transferable that is introduced later or by any objects that other specifications separately define as transferable (https://html.spec.whatwg.org/multipage/structured-data.html#transferable).

To modify Domenic s example a bit.. it would be something like... const holder = new TransferableHolder(anyTransferable); const thing = holder.take();

The question then becomes what objects are Transferables? We can introduce two new well-known Symbols to address that and the relevant use cases: Symbol.transfer and Symbol.clone.