The specification does not implementations. See e.g.
<script> var x = new ArrayBuffer(10); postMessage(x, "*", [x]); w(x.byteLength) </script>
in
http://software.hixie.ch/utilities/js/live-dom-viewer/
That works fine and does not throw. I suspect this might be a wider issue (the specification not matching implementations), we encountered this when looking at how ArrayBuffer should behave in the context of platform APIs.
so what do you think should happen byteLength still works and returns 0? The Khronos Array Buffer spec. doesn't say, one way or another?
Is this returns 0 behavior currently universally implemented? I'm having trouble getting the test case to work on IE11 and Safari.
Are there any other undocumented expectations WRT neutering?
I believe we should update ArrayBuffer byteLength to return 0 for a detached array buffer because:
1) Google maps appears to depend on this behavior
2) This is how it is currently implemented in Chrome
3) TypedArrays now return 0 instead of throwing when attached so it makes sense to be consistent.
I think this should also apply to DataView.prototype.byteLength and DataView.prototype.byteOffset (eg. neither of these should throw, all byteLength and byteOffset accessors should return 0).
It seems strange that only these accessors should return 0 and the prototype methods throw, but if we can get away with prototype methods throwing (seems like we can) I think this is ok.
(In reply to Brian Terlson from comment #3)
I could easily make this change, however, the margin comment in the draft says the TC39 at its June 2014 meeting decided it wants this to throw see https://github.com/tc39/tc39-notes/blob/master/es6/2014-06/jun-4.md#48-arraybuffer-neutering).
Do you want to raise this on the reflector? If you resolve it quickly I can still make the change.
(In reply to Brian Terlson from comment #3)
so are you ok with the status quo or do you still want ArrayBuffer.byteLength to throw?
currently works are intended by TC39 and nobody has taken it to TC39 to try to change that decision.
If implementations find this change untenable we can always change it in ES7...