On Feb 14, 2014, at 12:46 PM, C. Scott Ananian wrote:
>/ For reference:https://bugs.ecmascript.org/show_bug.cgi?id=2546
/>/
/>/ `Array#copyWithin` has a (non-normative) signature of `(target, start,
/>/ end = this.length)`. However, this is slightly misleading because the
/>/ spec actually calls `ToLength` on `this.length` and then uses *that*
/>/ for the default value of `end`. This changes `end`'s effective value
/>/ when `this.length` is negative.
/>/
/>/ In the bug we discuss changing the non-normative descriptive text to
/>/ be less misleading.
/>/
/>/ But I'd like to invite broader discussion on a different approach: can
/>/ we change the spec so that the `end = this.length` default was
/>/ actually correct? This would only possibly change behavior on
/>/ array-likes with negative length, and probably wouldn't even change
/>/ observable behavior in that case (since `length` is treated as 0).
/>/ Basically we'd be just calling `ToInteger` on the default value of
/>/ `end` rather than `ToLength`. But it would be an end-run around
/>/ confusing language in the spec.
/>/ --scott
/
ToLength is used a number of places within the ES6 spec. where formerly
ToUint32 was used. It allows indices to be larger 2^32-2 and avoids weird wrap
behavior for indices in that range. I doubt that we could compatibly get away
with replacing those legacy ToUnit32 calls with a ToLength that preserved
negative values. Even if we could we would have to review all of the array
(and string) algorithms that use ToLength to make sure they still work
reasonably with negative length values. I really don't see what benefit we
would get from that work.
Allen
I think Scott is requesting this change:
https://gist.github.com/anba/6c75c34c72d4ffaa8de7
- André
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
