Repository navigation
[js-api] Globals of type anyref require slight adjustment to JS API spec #20
Description
At the moment, the JS API spec requires that if the value argument to the WebAssembly.Global constructor is undefined then the default value for the Global's type is stored. For a Global of type anyref this probably means that the value stored is null. But this is counter to the intent of anyref, which is that it can represent (through boxing) any host type faithfully.
This is not a compatibility issue since anyref is a new thing and the problem is not observable with older types, it's just a slight complication of the algorithm for Global's constructor. I'm not sure if this means the WebIDL spec for that constructor needs to change, ie, if the current behavior is a result of some WebIDL standard behavior. If it does need to change then compatibility may be slightly at risk, though no doubt a fix can be found.
Activity
rossberg commentedon Nov 27, 2018
Just to clarify, is your suggestion to only default to null if the value parameter is absent (as opposed to undefined)?
lars-t-hansen commentedon Nov 28, 2018
Yes, I think that pretty much sums it up.
rossberg commentedon Nov 28, 2018
Sounds good to me.
titzer commentedon Nov 28, 2018
Generally OK with this. I guess this suggests an implementation strategy of internally checking arguments.length? (since this diverges from normal JS behavior for missing arguments, it's a slight wart).
rossberg commentedon Nov 28, 2018
You'll find enough precedence in the ES spec itself where a "not present" argument is treated differently from the value undefined. Random bad example: all the Date.prototype.set* functions.
[-]Globals of type anyref require slight adjustment to JS API spec[/-][+][js-api] Globals of type anyref require slight adjustment to JS API spec[/+]rossberg commentedon Jan 16, 2020
This has been fixed.