Detached TypedArray access semantics

Brendan Eich brendan at mozilla.org
Wed May 6 18:10:22 UTC 2015


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


More information about the es-discuss mailing list