sfink notes on immutable ArrayBuffer

immutable-arraybuffer.md

• (non-spec) should immutable ABs always have immobile data? (Are there inline immutable ABs?) I was thinking that if you have an immutable AB or a frozen view of one, that we could freely hand out internal pointers. But with inline or nursery-allocated data, that is still not necessarily safe.

• would an explicit borrow mechanism like https://gist.github.com/domenic/a9343fa787ba54b4ba3a60882c49cc32 cover the use cases here?

  • it's not a great match for ROM views. "I own this view and nothing else is going to write to it" doesn't say what happens when you try to write anyway. Failing or throwing violates the spec. CoW would "fix" it, but would basically be a big lie.

• the Motivation section in the proposal is persuasive (both examples)

• the added methods (transferToImmutable and sliceToImmutable) make things start to feel a little clunky, when added to transferToFixedLength, like there should be a more general transfer/slice mechanism that covers the full set of transformations we might end up with (fixed length, immutable, shared, resizable, ...?)

  • could there end up being transformations where we'd do something different in a one-step process as opposed to a two-step? eg resizable -> fixed length immutable vs resizable -> fixed length -> immutable? (That's probably not the best example, but the real example might be some future variant.)
  • at the very least, each transfer* creates a new ArrayBuffer, so the two-step process creates a junk temporary ArrayBuffer. Not the end of the world.

• overall, looks good. No real concerns. I was worried it might have wrinkles or suggestions to facilitate mprotecting the data, and am happy that it omits any mention of that entirely.