Normative: move 'into' methods onto prototype and rename

[bakkot]

Fixes #41. In Matrix (x, x) people mildly favored having these on the prototype, and while there wasn't universal agreement on the names no one objected strongly to setFromBase64, which was my favorite.

I'm going to leave this open for the moment to get more eyes on it.

cc @anba

Also cc @annevk since this breaks some symmetry with encodeInto (but, I think, probably not in a way which will be confusing for users - no more than having a toBase64 prototype method vs (new TextDecoder).decode, anyway).

[ljharb]

Changes are 100% correct, assuming the base spec is correct and the change ends up with consensus :-)

[anba]

Suggested change

	1. Let _into_ be the *this* value.
	1. Let _into_ be the *this* value.
	1. Perform ? ValidateTypedArray(_into_, ~seq-cst~).

Here and below to match other TypedArray.prototype built-ins.

[bakkot]

The closest such built-in is TypedArray.prototype.set, and it, like this method, initially checks only the presence of the internal slot on this, and then does the potentially side-effecting handling of arguments, and only after that does the IsTypedArrayOutOfBounds check.

That's what I'm doing here.

[anba]

TypedArray.prototype.set (and TypedArray.prototype.subarray) are both legacy Khronos-based functions, so I don't think it's useful/necessary to copy the same approach in new methods. Instead it's preferable to use the same validation sequence which is present in all newer TypedArray built-ins.

[anba]

(Actually it'd great if we could change TypedArray.prototype.{set,subarray} to call ValidateTypedArray at the start, because it's kind of annoying that subarray can observe the original [[ByteOffset]] when the underlying buffer is detached, see https://bugzilla.mozilla.org/show_bug.cgi?id=1291003 and https://bugzilla.mozilla.org/show_bug.cgi?id=1840991. Being able to read [[ByteOffset]] from detached/out-of-bounds typed arrays also requires extra JIT support in SpiderMonkey, where subarray is a self-hosted built-in: https://phabricator.services.mozilla.com/D200658.)

[bakkot]

You want to get the length (and validate non-detachedness) after side-effects happen anyway. Checking up-front would mean duplicating that work.

[bakkot]

cc @syg for thoughts.

[syg]

You want to get the length (and validate non-detachedness) after side-effects happen anyway. Checking up-front would mean duplicating that work.

I agree with this.

I'm leaning towards breaking with consistency. If we do that, the most desirable processing order for TypedArray builtins are to first process all the parameters, then do a ValidateTypedArray on this. After that point, with the exception of built-ins that call user-provided callbacks in a loop (like map or something), there should be no more user code being called.

If for whatever reason committee is not amenable to breaking with consistency, the ValidateTypedArray on this, then arguments, then ValidateTypedArray again order is wasteful. And given that maximal consistency is not possible since the builtins are already inconsistent, I see no compelling reason to be wasteful.

[sffc]

Reducing the number of positional arguments is good, and the prototype method reduces the number of positional arguments.

[bakkot]

Got consensus for this change.

[bakkot]

Test262 tests have been updated.