Expose whether an `ArrayBuffer` is detachable

まず、ArrayBuffer の現在の detachability ルールと、この issue で説明されている transfer() の動作を確認します。detachability の boolean プロパティが、指定された極性および WebAssembly.Memory のケースを含めて、この proposal に適合するかを評価します。仕様上の決定に到達し、それを文書化できれば完了です。

There is a pre-existing problem with ArrayBuffers in that it is not always possible to determine up-front whether or not a particular instance will succeed in being detached when asked to be transferred. Prior to this proposal, the notable case of an undetectable non-detachable buffer was the buffer exposed by WebAssembly.Memory. (This is as opposed to SharedArrayBuffer, which can be detected via instanceof.)

This proposal adds a new reason that an ArrayBuffer might not be detachable, and it requires a kind-specific check (.immutable) to make the detachability determination. And it seems likely that this won't be the last kind of buffer that won't be detachable.

I'd like to suggest that the fact of detachability be directly represented as a detachable: boolean property. It would be true exactly when a request to transfer() would succeed based on the detachability criterion. The choice of polarity here is intentional, in that an implementation without the property would fail-safe in terms of client code trying to decide between copy or transfer.

To be clear, it is currently possible to recover from a failed transfer with try-catch if one is trying to implement copy-or-transfer. However, that means that a correct case would have to accept the inefficiency of generating and catching an exception. And beyond that inefficiency, it does not make for particularly ergonomic code. And, in general, it's just plain useful to be able to make the determination without actually trying.

I actually ran into exactly this case (wrt WebAssembly.Memory) and during my search for a resolution ended up finding this proposal. So I figured it'd be worth raising the suggestion here. In my case, it was preferable to accept that my code will throw rather than silently degrade performance (punting the performance problem to the caller), but I'd really rather not be in the position to have to make that tradeoff.