If the array is detached spec says 6. If IsTypedArrayOutOfBounds(srcRecord) is true, then Let srcLength be 0.. IsTypedArrayOutOfBounds() considers a detached array out of bounds, so that takes effect and srcLength=0, however further below we don't do the same with the srcByteOffset. That seems inconsistent at first sight. Why does it make sense to preserve the byteOffset from a detached buffer; is it deliberate or it's a spec omission?
It would seem that If IsTypedArrayOutOfBounds(srcRecord) is true, then Let srcByteOffset be 0 would be more reasonable to have.
Maybe a simple example can help. This assumes we run in a test environment which has the ability to detach a buffer. The example is from the linked test262 test but a bit shorter.
const elementSize = Float64Array.BYTES_PER_ELEMENT; // 8
let buffer = new ArrayBuffer(2 * elementSize);
let typedArray = new Float64Array(buffer, elementSize, 1);
typedArray.constructor = {
[Symbol.species]: function(_, offset, _) {
print("elementSize: " + elementSize);
print("offset: " + offset);
return new Float64Array(1);
}
};
let end = {valueOf() {$262.detachArrayBuffer(buffer); return 0;}};
typedArray.subarray(1, end);
Currently we print the offset = 16, but I wonder if we detached the buffer if it makes sense to still access the offset from it.
After reading your code sample I think the test is correct.
According to the spec text for subarray the buffer isn't yet detached in step 6, so it's fine to obtain the offset in step 13. The buffer only becomes detached in step 16.a, as a side effect of ToIntegerOrInfinity.
According to the spec text for subarray the buffer isn't yet detached in step 6, so it's fine to obtain the offset in step 13. The buffer only becomes detached in step 16.a, as a side effect of ToIntegerOrInfinity.
Oh, now I see it! That makes perfect sense. Thank you for explaining, @ptomato