ArrayBuffer neutering

Allen Wirfs-Brock allen at wirfs-brock.com
Wed May 21 10:18:25 PDT 2014


On May 21, 2014, at 9:59 AM, Dmitry Lomov wrote:

> 
> 
> 
> On Wed, May 21, 2014 at 5:19 PM, Allen Wirfs-Brock <allen at wirfs-brock.com> wrote:
> 
> On May 21, 2014, at 2:02 AM, Dmitry Lomov wrote:
> 
>> 
>> >
>> >> Finally, I note that the current Khronos spec. doesn't provide much guidance in this regard.  The thing it has that is most similar to the other array methods is the 'subarray' method and it doesn't explicitly say anything about what happens when it is applied to a TypedArray with an underlying neutered ArrayBuffer.
>> >
>> > It isn't clear to me that it needs to. Starting from a view which is
>> > pointing to a neutered ArrayBuffer, there is no way to create a
>> > subarray of any nonzero length.
>> 
>> No, but it seems highly unlikely that anybody doing myTypedArray.subarray(5,10) actually wants to get back a 0-length array is myTypedArray happens to be neutered.
>> 
>> Maybe, but I believe we have been shipping 'subarray' with exactly this behavior for quite a while now, and speccing it otherwise will be a compat hazard.
>> 
> 
> I didn't say that the pre-existing subarray method should change its behavior.  But I am proposing that the new methods being added by ES6 fail hard if they encounter a neutered object.
> 
> I think it would be weird if some of them fail hard and some would behave as if the length is zero. Consistency is always good.
> Why "fail hard" is more desirable?
> 

Because trying to invoke any of these methods (we're talking about thinks like map, filter, reduce, copyWithin, sort, etc.) on a neutered TypedArray is surely a logic bug (can you think of any case where it isn't).  Throwing helps people find such bugs.

The only inconsistency is with the single legacy method 'subarray'.  Personally, I'd be fine with trying to also change it to throw.  Again, can you think of any case where doing someNeuteredArray.subarray(10) isn't a bug?

Allen

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140521/f7a55505/attachment.html>


More information about the es-discuss mailing list