@syg – With this proposal up for Stage 4 next month, is there a resolution to this? (Apologies if there was a change that I missed)

Oh man I missed this issue, thanks for the ping. My preferred fix is to transpose steps 4 and 5 in the resize algorithm. I'll tag on a quick normative item to the agenda. If there's discussion I'll defer the Stage 4 ask. @phoddie WDYT about transposition instead of repeating the check?

Edit: The transposition fix would be in line with what we did in #99

Chrome already has the transposed semantics. At a quick glance I can't quite tell what Safari would do.

@syg – I agree that performing the detached buffer check only once is best. And it should absolutely be normatively defined. My preference would be pull ToIntegerOrInfinity all the way back to step 2, so any changes a script might make would be before validating the ArrayBuffer. Practically speaking it may not matter now, but perhaps in the future.

FWIW – Step 22 of ArrayBuffer.prototype.slice helpfully notes that preceding steps may have caused chaos. That's nice for implementors. Perhaps appropriate here, depending on the change.

Putting it as Step 2 is an option, though slightly inconsistent with previous choice in #99, which I think is characterized by "mostly do coercions and checks in receiver, then left-to-right parameter order, but the detach check can be delayed to avoid rechecking". Whereas putting the ToIntegerOrInfinity to Step 2 would be more characterized as "do coercions and checks of all the parameters that might cause detachment, then do receiver checks". Both are valid choices and I think effect on ergonomics is negligible. And given the choice we made in #99, I prefer to just stick with it.

@phoddie I've added this item to the agenda for July.

@syg – I don't have a very strong opinion on this, so let's see what comes out of plenary.

From an implementer perspective, safely checking the arguments can be challenging to get right, so I'm happy if the spec provides safe guidance. The order of checks seems unimportant. How many developers have an intuition about that and would then depend on it? As long as engines implement the spec steps consistently, it should be enough.

How many developers have an intuition about that and would then depend on it? As long as engines implement the spec steps consistently, it should be enough.

I don't disagree! There are other delegates who in the past have expressed strong opinions that argument checking order ought to be preserved as much as possible though.

As a data point, I am a delegate who likes to preserve argument checking order, but if there's implementation reasons to do things in a different order I am OK with violating the usual order.