[js-api] Allow creating i64 globals

[rossberg]

The JS API does not yet support i64 for functions or globals because JS cannot represent int64.

However, there is no reason to disallow creating WebAssembly.Global instances of type i64. It is sufficient to disallow accessing them from JS through the getter and setter. After all, such objects can already be created indirectly by exporting an i64 global from a module.

I hence suggest the following relaxations:

• The algorithm ToValueType does not throw on "i64" but return i64.
• The algorithm DefaultValue does not throw on i64 but return (i64.const 0).

That way, a Global of type i64 can be created in JS but only with a default initialisation value.

Motivation: It is problematic for a generic linker, mocker or other module-level abstractions if they cannot externally create every possible export object (even if unusable in JS).

[littledan]

Given that BigInt is already relatively far along, I wonder if it would make sense to make this change together with the WebAssembly i64/BigInt integration proposal. This could leave the world with fewer states in the compatibility matrix to worry about. Anyway, @rossberg 's proposal doesn't seem so bad to me.

[rossberg]

BigInt support is not going to be in 1.0. This suggestion is to tweak what we ship in 1.0, so not gonna change the size of the matrix.

[littledan]

If WebAssembly has already shipped to the web without this feature, it's part of the matrix even if the 1.0 document already includes the feature.

[rossberg]

The Global constructor has not shipped in most browsers yet.

[xtuc]

This issue has been closed by #829.

During WebAssembly/meetings#268, we discussed about coercing values to/from i64 for function exports and globals but It's not covered by #829.

[rossberg]

Right, closing this. Allowing coercions is a separate question.