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.
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 byWebAssembly.Memory. (This is as opposed toSharedArrayBuffer, which can be detected viainstanceof.)This proposal adds a new reason that an
ArrayBuffermight 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: booleanproperty. It would betrueexactly when a request totransfer()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-catchif 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 willthrowrather 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.