9.4.5.2 [[HasProperty]](P)
9.4.5.2 step 3.c should probably only return `true` for own valid indices, and in every other case default to OrdinaryHasProperty.
---
If IsInteger(index) is true and index /= -0 and index >= 0 and index < [[ArrayLength]], return true.
---
It's not clear to me that your suggestion is correct because [[Get]] returns undefined for those property keys and [[Set]] refuses to set them.
So, from that perspective it looks like the don't exist. Even if if they are defined further up the prototype chain chain.
OrdinaryHasOwnProperty, if it was called for them would climb the prototype chain and find them. Isn't it more consistent to report that they don't exist if they can't be accessed.
It's weird that such properties appear to exist if you start look at the prototype and appear not not exist if you start with the leaf object. But the MOP actually allows that to occur.
(In reply to Allen Wirfs-Brock from comment #1)
> OrdinaryHasOwnProperty, if it was called for them would climb the prototype
> chain and find them. Isn't it more consistent to report that they don't
> exist if they can't be accessed.
>
In that case I'd expect the following algorithm sub-steps in 3.c:
---
i. Let buffer be the value of O’s [[ViewedArrayBuffer]] internal slot.
ii. If IsDetachedBuffer(buffer) is true, throw a TypeError exception.
iii. If IsInteger(numericIndex) is false, return false.
iv. Let intIndex be numericIndex.
v. If intIndex = −0, return false.
vi. If intIndex < −0, return false.
vii. Let length be the value of O’s [[ArrayLength]] internal slot.
viii. If intIndex ≥ length, return false.
ix. Return true.
---
I was just about to file exactly the same bug, after implementing ES6 HasProperty. The current behavior makes 'in' on typed arrays pointless.
fixed in rev33 editor's draft
just like Comment 2
fixed in rev33