DataView byteLength/byteOffset still specified to throw when buffer detached

[bathos]

ArrayBuffer & TypedArray accessors were adjusted to no longer throw when the buffer is detached. If I understand right this was motivated by several factors, one of which was existing inconsistency between implementations, some of which already didn’t throw.

The stop-throwing changes didn’t include DataView. It’s still specified with the “old” behavior in its byteLength/byteOffset getters. At the time @rwaldron had commented:

While reviewing & writing tests for this, I noticed that DataView.prototype.byteLength is not included in the changes, but is currently spec'ed to throw on detached array buffers. Implementations currently do not agree.

(I’m not sure what the current situation is for behavior between implementations.)

Could be factors in play that I don’t know about, but it seems a lot like DataView should have gone along for the ride when the others changed. Consider code like if (ArrayBuffer.isView(x)) return x.byteLength — that’s a pretty well-hidden edge case baked in there, the sort that could sit around for a very long time without being noticed since the conditions for tripping the surprise-throw are very narrow. The API surface seems to encourage the assumption that this should behave consistently for all views.

(Also, though this is probably very subjective, from my POV getters that throw are kind of a “surprise” to begin with. Like, unless it’s a super deliberate/unilateral thing like with caller, where it’s saying “don’t do this (at all).” For properties that are actually meant to be used which normally just return numbers, it seems like a weirdly hostile pattern.)

Originally posted by @bathos in #678 (comment)

[ljharb]

Almost every getter in the language throws when the receiver lacks the right internal slots.

[bathos]

Yes, and that makes sense, I meant patterns where a getter throws or does not throw with the same receiver according to its (or in this case, another object's) current state.