Shu-yu Guo

Cool, I like the suggestion in https://github.com/WebAssembly/spec/issues/1292#issuecomment-789329628.

> so from a purely semantic standpoint it would make sense for this to be the observable max in JS for a Wasm memory with no explicit max, rather than...

> when we get 64-bit memories, may be somewhat lower than 2^64. Oh, that's gonna be a tricky thing on the JS side. ArrayBuffer sizes aren't BigInts, nor can BigInts...

> EDIT: the value is in fact fixed by the JS API, so that should be the number used for the max field. No need to say it's implementation defined...

> The inner bullet just after that line says that the ResizableArrayBuffer can never be detached. In my head, once the .resizableBuffer attribute is accessed for the first time, subsequently...

@aardappel But how do you address very large indices? Not all i64s fit inside of a float64. Edit: pesky double negatives

@aardappel @conrad-watt Thanks for the clarification. Sounds good to me.

Unfortunately I didn't add it in time to the next meeting before the agenda was filled up. I've added it to the https://github.com/WebAssembly/meetings/blob/master/main/2021/CG-03-30.md, which should also give enough time to...

ecma262 does not prohibit Chromium's behavior. There is no normative requirement of NaN canonicalization. NaN bit patterns are not observable outside of TypedArray writes and reads, so NaNs are indistinguishable...

The converse is also helpful to lint: AOs that do not return completions must not be annotated with any of the three options above.