Closed
Description
- It reads a little less clear to me to change the hardcoded booleans to
mutable
in https://tc39.es/proposal-immutable-arraybuffer/#sec-typedarray-defineownproperty in steps iv and vii - it should be an editorial error if mutable is true and writable is also true, and assertions might be a clearer (albeit more verbose) way to ensure that correctness here. - It kind of seems like it might be simpler in [[DefineOwnProperty]] to have two branches - the mutable one would be unchanged, and the immutable one would only have to check whether the descriptors differed or not in any way.
Editorial: Split TypedArray [[DefineOwnProperty]] into distinct branches by mutability #32 - why would https://tc39.es/proposal-immutable-arraybuffer/#sec-typedarraysetelement ever be called with an immutable buffer, with the current spec? it seems like maybe it'd be better to add an assertion in step 1 that isImmutableBuffer is true? (i'm looking at [[Set]] right above it, which seems to skip calling TypedArraySetElement when the buffer is immutable, but please clarify if i'm misunderstanding)
- am i correct that an arraybuffer's mutability can never change, it's set at creation time?
- it seems strange that immutable and mutable arraybuffers have different slots - rather than
[[ArrayBufferIsImmutable]]
, why not a single slot with a boolean that's on every arraybuffer? - i think the note in https://tc39.es/proposal-immutable-arraybuffer/#sec-arraybuffercopyanddetach maybe needs to be moved down one, so it's above the CopyDataBlockBytes call?
- re the first TODO in https://tc39.es/proposal-immutable-arraybuffer/#sec-arraybuffer.prototype.slicetoimmutable - which check is redundant, the isSAB check or the isDetached check, and why?
- the 2 TODOs in https://tc39.es/proposal-immutable-arraybuffer/#sec-arraybuffer.prototype.slicetoimmutable don't seem to be related to Order of operations, when to throw or silently do nothing? #16; should they be resolved prior to advancement?
Metadata
Metadata
Assignees
Labels
No labels