Open bvisness opened 2 days ago
The interaction of this proposal with custom page sizes is a good point! I think we have to make memory.grow/size use the index type to count pages in this proposal, otherwise it will not be forward-compatible with custom page sizes, and impossible to fix later. I opened #69 for that.
As I finalize our implementation of table64, I'd like some clarity on the JS API. Some previous comments (e.g. https://github.com/WebAssembly/memory64/issues/46#issuecomment-2072933689, https://github.com/WebAssembly/memory64/issues/46#issuecomment-2072979502) have suggested that
.get
,.set
should accept both number and BigInt for their indices.However, I'd like to clarify a couple things:
i64
params must be BigInt (per ToWebAssemblyValue), so should BigInt be required for Table methods as well?Table.grow
take?Memory.grow
currently takes a number, even for memory64, despitememory.grow
taking ani64
. Perhaps this is just because the param is in units of pages? (But, if custom page sizes are coming down the pipe, this reasoning won't hold up for long.)My suggestion would be for all of
Table.get
,Table.set
,Table.grow
, andMemory.grow
to require BigInt when the index (address :slightly_smiling_face:) type isi64
. This is consistent withToWebAssemblyValue(v, i64)
, and therefore consistent with the core wasm versions of these instructions.Altering
Memory.grow
should also be backwards-compatible at this stage since memory32 is unaffected - although it may cause slight difficulty for toolchains in practice. Worth it imo (but I am not a toolchain author).