Ben Smith

Yeah, there is a potential compatibility risk here, but I think it's low, and decided having uniformity is nicer. I believe we came to the same conclusion at a CG...

The hope was that the existing usage would be covered by the `@@toPrimitive` hook, and most users won't care that they're getting a different object under the hood. I also...

Yeah, I was pushing for uniformity mostly because I didn't think it would be an issue. But if it is (or if we think it may be, and aren't sure)...

That's a good idea. It might be worth bringing up at the CG how this would go through the [phases](https://github.com/WebAssembly/meetings/blob/master/process/phases.md), considering it's a JS facing change only.

We discussed this at the Nov 28 CG. Some notes: * It's useful to have WebAssembly.Global for immutable globals, since we may not be able to express the type in...

This is mentioned briefly in [FutureFeatures.md](https://github.com/WebAssembly/design/blob/master/FutureFeatures.md#full-ieee-754-2008-conformance) for scalar floats.

@conrad-watt thoughts on how something like this would work with the memory model?

We discussed this at the Nov 12th CG meeting, and decided to use the unsigned semantics for wake. We also decided to trap during wait if there would be be...

I dunno, I'm having a hard time imagining a scenario where we'll wake 4 billion threads (or even async waiters). But either way, I'm fine with either solution. Let's bring...

Added poll. > The change to the spec still just says "converted to i64". Maybe there's a canonical definition of that word that I've missed; barring that, the nature of...