Repository navigation
[js-api] WebAssembly.Table.prototype.grow and a fill value #22
Description
The envisioned table.grow instruction takes a required fill value as a second argument. We should similarly change WebAssembly.Table.prototype.grow to accept a fill value, indeed for non-nullable element types we must have a fill value. Here are some notes about that.
Backward compatibility concerns when the table is table-of-anyfunc:
- the second argument must be optional
- the default value of the optional second argument must be null
- if the second argument is present but is not a function value that can be stored, then it must be ignored
For table-of-anyref it is probably most correct if the default value for the optional second argument is null, not undefined, since null is a value that is in wasm, unlike undefined. (This matters only because undefined is representable as an anyref value and is thus a candidate at least in principle.) FWIW, the table.grow instruction cannot talk about undefined values without getting them from the host, but it can synthesize null. A JS caller to WebAssembly.Table.prototype.grow() can pass an undefined value explicitly as the second argument to initialize new slots with that value.
Long-term it's inevitable that the behavior of W.T.p.grow depends on the table type anyway; for non-nullable element types there can be no default, for example. We could choose now to require the second argument also for anyref tables, we would just have to leave anyfunc tables as a special case.
Activity
[-]WebAssembly.Table.prototype.grow and an initializer argument[/-][+]WebAssembly.Table.prototype.grow and a fill value[/+]lars-t-hansen commentedon Nov 30, 2018
I guess accepting a second argument here for table-of-anyfunc is technically incompatible with existing code that does pass an exported wasm function as the second argument, since that argument would previously be ignored but now will not be.
rossberg commentedon Nov 30, 2018
Agreed with this proposal. For non-nullable table types leaving of the default should cause a TypeError, of course, but the simplest way to achieve that probably is to define null as the default for all reference types in the API. Then the later check will throw the error anyway.
The ES spec has added additional arguments to some of its functions in the past, so we should be okay doing the same.
lukewagner commentedon Dec 17, 2018
Just to confirm: do we all agree it's ok to break backwards-compatibility by changing the case where a non-exported-wasm-function JS value is passed as the second argument to
Table.prototype.growfrom silently ignoring to throwing?I ask because @Ms2ger judiciously wrote a wpt for exactly this case that fails if we make this breaking change, but I expect (and we can verify in FF by immediately landing a throw-if-passing-any-second-argument patch ahead of full bulk-operations) that this breaking change won't actually break web content. If the assumption is correct, that means we'd change the wpt to test for the throwing behavior.
Make sense to everyone? [cc @Ms2ger @littledan ]
Ms2ger commentedon Dec 18, 2018
It makes sense to me to throw on any invalid values here. Please do update the test, and add one for the three-argument case :)
[-]WebAssembly.Table.prototype.grow and a fill value[/-][+][js-api] WebAssembly.Table.prototype.grow and a fill value[/+]rossberg commentedon Jan 16, 2020
It's in the embedder interface, but the JS API still needs to add the init argument.
@littledan, would you be willing to look into this?
wingo commentedon Jan 17, 2020
I'll take it if that works for y'all. Am out of the office next week but will pick it up the week after.
rossberg commentedon Jan 19, 2020
Thanks @wingo. By any chance, would you be willing to also look into #51 and #67? Those seem to be the other open issues around the JS API. Both of them should be fairly easy to fix.
rossberg commentedon Feb 8, 2020
@wingo, any update on this? Would be good to have this fixed before the meeting on Tuesday.
wingo commentedon Feb 10, 2020
Hi, sorry for the delay; didn't realize how much travel would discombobulate me :P No update currently, but I will switch to this task to see if I can finish by tomorrow.
[js-api] Extend the WebAssembly.Table API.
[js-api] Extend the WebAssembly.Table API.
[js-api] Extend the WebAssembly.Table API.
lars-t-hansen commentedon Feb 25, 2020
@wingo, any update?
Ms2ger commentedon Feb 25, 2020
@lars-t-hansen see #79