Ryan Hunt

@rossberg > Also, why would they care about numerics specifically? If there was a reason to under-specify other, non-numeric instructions in future versions of Wasm, they'd probably want those fixed...

@lukewagner > Since the deterministic profile is more-widely deployed in production and since, until we add threads, the deterministic profile is the same as the numeric-determinism profile, I'd suggest we...

> Right, but that ought to be a problem for the threads proposal, the Relaxed SIMD proposal can remain entirely agnostic to that choice (up to possibly naming, which isn't...

> 2. **"Mozilla suggested this does not fit well into SpiderMonkey"**: What in specific is the problem with this suggestion in relation with SpiderMonkey? Would this be resolved with "pre-imports"...

Trying to touch on a couple of the different discussion points here. 1. Normal function imports are not useful here because names are not significant and the imported function is...

@SPY . So if I export a function like: ``` (type $s (struct ...)) (func (param (ref $s)) ``` And call `.type()` on it, I will get: ``` { params:...

I think this makes sense. Do you know if there is any precedence for this with other function objects that derive from Function.bind?

I think this could make sense if it showed some good size decreases. With respect to the linked js-string-builtins issue, that discussion isn't finished yet and we may settle on...

> Would it be safe to say that compact import sections would allow string constants in the js-builtins proposal to use the same `wasm:...` module string as all the other...

> There's a few questions in this design space that might be interesting to discuss: > > * What happens when the memory that's discarded is accessed again? In the...