Conrad Watt
Conrad Watt
> If an instruction was added where the entire purpose is to be 'invalid', making that instruction 'valid' would be a breaking change. I agree that this is true in...
To bikeshed, there's also a world in which `invalid` doesn't show up in the instruction list of the [AST](https://webassembly.github.io/spec/core/syntax/instructions.html#instructions), but has an explicit entry in the text format and binary...
> I don't understand. The way something is spec'ed as a syntax error is by having no grammar rule for it. Which is exactly the status quo. Ultimately this is...
The fields of the `memoryDescriptor` currently correspond precisely to the components of the type of the memory in core Wasm. Would it be acceptable for _all_ memories to have a...
> Vending a ResizableArrayBuffer/GrowableSharedArrayBuffer is mutually exclusive with vending a plain ArrayBuffer/SharedArrayBuffer. Does this have to be the case? Having the same Wasm memory backing both (e.g.) an `ArrayBuffer` and...
In that case something like https://github.com/WebAssembly/spec/issues/1292#issuecomment-789303914 does seem like the immediate path of least resistance, although if buffer aliasing were to sneak into JS through some other avenue, I'd hope...
Alternatively, maybe the first vend of a`ResizableArrayBuffer` could permanently detach the associated `ArrayBuffer` (including subsequent results of `.buffer`), while vending a `GrowableSharedArrayBuffer` is just allowed to alias with the associated...
With reference to the OP... > - If the `Memory` was created with a maximum size, that size will be reflected on the `ResizableArrayBuffer` or `GrowableSharedArrayBuffer` instance. > - Otherwise,...
> That makes sense to me, I'll update the OP. Just to be clear, after some pondering I think that it makes sense for the length in this case to...
> Oh, that's gonna be a tricky thing on the JS side. ArrayBuffer sizes aren't BigInts, nor can BigInts be property keys currently. AFAIK we haven't explicitly discussed JS integration...