[js-api] Globals of type anyref require slight adjustment to JS API spec

[lars-t-hansen]

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.

[rossberg]

Just to clarify, is your suggestion to only default to null if the value parameter is absent (as opposed to undefined)?

[lars-t-hansen]

Yes, I think that pretty much sums it up.

[rossberg]

Sounds good to me.

[titzer]

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]

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.

[rossberg]

This has been fixed.