[bakkot]

This note became incorrect with the introduction of resizable ArrayBuffers, though arguably it was already incorrect given ArrayBuffer detaching. As reported in #4013 by @JinDX.

I think the "no user code" note is useful; the UC annotation doesn't suffice because it will tell you that SortIndexedProperties can call user code - which it can, but only by calling the user-provided comparator. That really can change the length of the TA during execution although the algorithm mostly doesn't care (it does all the reads before calling the comparator, and the trailing writes just don't happen if the TA ends up too small for them).

I'm open to dropping the "and the TypedArray's length cannot decrease" part since it's a little confusing in light of the up-front read.

[bakkot]

(Why do we even have this argument? What other way are you sorting the contents of a TypedArray?)

[github-actions]

The rendered spec preview for this PR is available as a single page at https://tc39.es/ecma262/pr/4043 and as multiple pages at https://tc39.es/ecma262/pr/4043/multipage .

[nicolo-ribaudo]

Suggested change

<p>This is a distinct method that, except as described below, implements the same requirements as those of `Array.prototype.sort` as defined in <emu-xref href="#sec-array.prototype.sort"></emu-xref>. The implementation of this method may be optimized with the knowledge that the *this* value is an object whose integer-indexed properties are not sparse. If _comparator_ is *undefined*, no user code is executed during this algorithm, and the TypedArray's length cannot decrease.</p>

<p>This is a distinct method that, except as described below, implements the same requirements as those of `Array.prototype.sort` as defined in <emu-xref href="#sec-array.prototype.sort"></emu-xref>. The implementation of this method may be optimized with the knowledge that the *this* value is an object whose integer-indexed properties are not sparse. If _comparator_ is *undefined*, no user code is executed by this algorithm, and the TypedArray's length cannot decrease.</p>

Since user code from other threads could still mutate the array values if it's baked by a SharedArrayBuffer, right? (which is why you added that the length cannot decrease).

(Why do we even have this argument? What other way are you sorting the contents of a TypedArray?)

Clearly for people that prefer lexicographic order!

[bakkot]

Done.