Hardening TypedArray

Currently, freezing a TypedArray throws, so harden throws. But

• typed arrays really ought to be directly marshalable for ergonomic reasons. The alternative is to wrap all typedarrays in a Blob wrapper of some kind
• hardening a Map or Set is morally equivalent to preventing extensions and making all properties non-writable on a TypedArray

Making a special case for typed array in harden poses a couple challenges:

Differentiating a typed array appears to require try/catch, and try/catch in a hot loop is expensive. try/catch deoptimizes the entire surrounding function, so the usual trick to making it go fast is to have an intermediate function on the stack between two optimizable functions. We could amortize the cost by making a freeze queue and a trampoline that may resume flushing the queue if freeze throws and verifying the type of the typed array does not.

The current best idea for inducing the isTypedArray check is:

Reflect.apply(Object.getOwnPropertyDescriptor(Object.getPrototypeOf(Uint8Array.prototype), Symbol.toStringTag).get, target, [])

as of 2022-01-28, by @mhofman

[erights]

Btw, this means a proxy of TypedArray cannot be hardened, since we’d be doing a brand check, and there’s no way for a proxy to pretend being a TypedArray.

Good catch! Uh oh. Fixing this will be complicated:

The proxy doesn’t have to pass the brand check. The proxy has to pass harden, and therefore isFrozen, while still acting adequately like a typed array. By adequately, I mean that it does SET and PUT of indexed properties “correctly”. But it does not need to pretend these are own properties. It can pretend to have inherited the indexed properties. I’d guess less than 1% of TypeArray code will care about this loss of fidelity.

Yuck! But I think it would work.

[mhofman]

Ah right, since the real index own props are non-configurable already, preventExtensions should be strictly equivalent to seal if we update all the descriptions of the other properties to non-configurable non-writable!