Allen Wirfs-Brock wrote:
On May 6, 2015, at 7:36 AM, Daniel Ehrenberg wrote:
In the draft ES6 spec, getting or setting array indices on detached
TypedArrays raises a TypeError. However, both V8 and SpiderMonkey
seem to return undefined from reads and silently succeed on writes.
These semantics have probably been shipping for some time.
As an implementer, I'm not sure what to do. Does anyone have any
information on whether it'd break the web to throw an error in this
case? What went into the decision to make these accesses throw an
error in the spec rather than the Chromium/Mozilla semantics? If it
would break the web, then should the spec be changed to match reality?
These issues were discussed at the June 2014 TC39 meeting, see
https://github.com/tc39/tc39-notes/blob/master/es6/2014-06/jun-4.md#conclusionresolution-12
"TC39 recognizes that the above are breaking changes relative to
the Khronos spec. but we believe that the behavior of silently
treating neutered buffers as 0-length buffers is seriously flawed
and would set a terrible precedent for any future "transferable"
data types."
As an implementor you should implement this change and expose it via
your pre-production release channels. Identify and analyze any
breakage that is reported. If there is limited breakage use
evangelism to try to get web developers to change their dependency
upon that behavior. Report back to TC39 if you discover that breakage
is wide-spread and cannot be remediated.
Thanks, Allen. I'd add that developers should use try-catch around any
.length tests of maybe-transferred arraybuffers. Such code is suspect
anyway (how can transfer fail? What's the fallback), but I'd welcome
real-world examples.
/be
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
