Open danfuzz opened 5 months ago
Just keep using
Buffer
s, mostly keep my fingers crossed, and sometimes make copies ofBuffer
s as a safeguard.
You can transfer array buffers into your control with the method of the same name:
const buffer = Buffer.alloc(100);
const transferredBytes = new Uint8Array(buffer.buffer.transfer());
buffer[0] = 12; // Effectively a no-op now
console.log(transferredBytes[0]); // 0
Regardless I agree that generally all buffer-like things should be accepted in all writer-like functions (the web does this).
What is the problem this feature will solve?
Because
Buffer
s aren't immutable, any time aBuffer
is passed to something which will perform an asynchronous write, there is a concurrency hazard where the buffer could conceivably get modified before it gets a chance to be written. This can lead to bugs which are hard to track down. (I speak from experience.)What is the feature you are proposing to solve the problem?
Anywhere where
Buffer
is currently accepted for a write operation, e.g. and perhaps most notablystream.Writable.write()
andstream.Writable.end()
, also make it acceptable to pass aBlob
.Blob
s are always immutable.What alternatives have you considered?
Just keep using
Buffer
s, mostly keep my fingers crossed, and sometimes make copies ofBuffer
s as a safeguard.(Note: It also makes sense to have a way to optionally have
Blob
s returned from readable streams, but I figure that'd be a different feature request.)