How should ArrayBuffer and SharedArrayBuffer be extended?

[syg]

There are three options:

1. Optional second parameter for maxByteLength: new ArrayBuffer(initial, maxByteLength).

   Problem: Possible web incompat. new ArrayBuffer(10, 5) doesn't throw right now but would start throwing. new ArrayBuffer(10, 20) would get new, different behavior.

2. Optional second option bag with maxByteLength property: new ArrayBuffer(initial, { maxByteLength: N })

   Has precedent in e.g. new Error(msg, { cause: ... })

   Problem: Still possible incompat, but exceedingly unlikely. I doubt there's any code in the wild that's passing an object into the second parameter with a maxByteLength property.

3. Static factory method: ArrayBuffer.resizable(initial, maxByteLength) (suggested by @jandem)

   Has precedent in e.g. Proxy.revocable and Array.from, though the Array.from analogy is a little weaker, as it's not creating a new kind of Array, but purely a convenience factory function.

   Problem: (from @bmeck) Need to mindful of composition with higher-order collection methods like Array.prototype.map.

The disadvantages of (1) outweigh its advantages, so I think the real choice is between (2) or (3). Given we have precedent for both, I'm leaning towards (2) since there's no possibility of any footguns with higher-order collection methods.

Also, I'm imagining that if I'm writing library code that may or may not make a resizable buffer, having an options bag meaning we can have a single construction site instead of having to decide whether to call new ArrayBuffer() or ArrayBuffer.resizable.

[ljharb]

2 > 1 for me, and I'm undecided on 3.

I don't think the .map problem is worth worrying about, since if a user doesn't know about that problem, they'll already run into bugs with countless other functions, builtin and third-party.

[syg]

Anecdotal as always, but Twitter poll is currently leading with option 2. I like that one the most too right now.

[syg]

For option 2, how do folks feel about having a more explicit property name with the word "resizable" in it, like maxResizableByteLength? Bikeshedding welcome.

[syg]

@DanielRosenwasser Any thoughts from TypeScript from a type checking point of view about this removal of the separate ResizableArrayBuffer type? I've heard from folks that thinking of resizability as a mode of existing ArrayBuffer is in fact more natural, so I'm inclined to think the lack of a type distinction at the AB level is fine, especially since TAs already don't get different language-level types depending on what kind of buffer they're backed by anyway.

[DanielRosenwasser]

People who will want to ensure resize() can't get called unless you constructed it as a resizable ArrayBuffer, and having an explicit subtype seems to be the best way to achieve that; however, it's not clear to me whether that's a must.

We'll inevitably get the request to disable resize() on plain ABs, and it will feel bad to turn it down; but I don't know if accidentally calling resize() is a real foot-gun.

[syg]

Decided on 2, closing.