JF Bastien

I think it's unrealistic, but at the same time I don't see a reason that we should restrict to i32 when we have native i64 support.

At the meeting yesterday we discussed trapping instead of saturating. Shouldn't JS do the same as well?

I thought we discussed throwing "on overflow", not necessarily at INT32_MAX 😁

Right, what I'm thinking is you're free to trap on i32 overflow, or on i53 overflow.

The WebAssembly CG didn't express a preference. Why would trap on i53 overflow be a no-go? This is from wake, which can check for that overflow easily, no?

The assumption was that we had a Number on the JS side.

It would be useful to understand which features we're talking about detecting. Right now I don't think anyone uses any feature detection, but when we ship say threads or SIMD...

Browser-side, validation already does feature detection as needed. It's strictly more work, and potential bug, for a browser to also support a feature detection section. I'm not saying it's useless,...

@nileshgulia1 you probably want to [check StackOverflow](https://stackoverflow.com/questions/47879864/how-can-i-check-if-a-browser-supports-webassembly/47880734) for questions like these.

That's half of the non-canonical stuff. It's missing the other half. And the maximum length. I can put everything in one section if that's clearer.