Immutable ArrayBuffer

[mhofman]

As part of Immutable ArrayBuffer, I think we'll need to consider whether we need an option to concat-to-immutable or is transfering-to-immutable-after-concat good enough.

Really want to take the path of least surprise with this.

Originally posted by @jasnell in #2

I very much want to find a way to produce an immutable ArrayBuffer without having to go through a mutable one first and call transferToImmutable.

It may be acceptable to automatically produce an immutable AB if all input buffers are themselves immutable, but this seems like a brittle path, subject to refactoring hazards when the producer of the chunk changes.

Since we are relying on an iterable as first argument, we do have the freedom to use a second (or other) argument to specify options for the buffer to be created.

[jasnell]

Yeah, been considering that also. An options bag makes sense

[bakkot]

Options bag also leaves room to allocate a resizable buffer, which there's fewer use cases for but is still a thing you could reasonably want.

[jasnell]

yep... ok... then concat(items, options) where options contains ... what initially?

• immutable - boolean
• maxByteLength - number ... could be used to both truncate the result (a la Node.js Buffer.concat second argument, or if the value is longer than the total length of items, could signal resizability?? Unsure about this one. Thinking we start with immutable only and add options separately in future.