Ben Smith

> Additionally, these proposals don't want to introduce new function calls at runtime, so ideally they would use some sort of compile-time import. I'd like to see the expected function...

> Unless we develop a framework for standardizing functions that must be available as imports, we would not only be saying that it is appropriate to implement the proposed functionality...

> I'm curious about option 3's goal of maintaining the "purity of the WebAssembly core semantics". It would seem that doing so would require thing we call "the WebAssembly core...

> The problem is that if we can formally specify the behavior of the import, we might as well just extend WebAssembly's semantics to describe the new behavior and make...

@taralx It may be possible to use the custom section to do that (at least for ITT and debugging, not sure if it works well for await). However, currently custom...

This topic came up again in today's GC subgroup meeting, where @tebbi presented on JS and wasm GC interop. There was an example of an instruction that modified a "Run-time...

WebAssembly typically doesn't provide numeric instructions for operations that aren't commonly available on hardware. That's why there isn't a `f32.sin` or `f32.cos` either, though they would probably be useful. Perhaps...

Well, if you're interested in championing the feature, I'd suggest presenting a proposal with some data at the [next CG meeting](https://github.com/WebAssembly/meetings/blob/master/2017/CG-10-03.md). That's coming up pretty soon, but even something preliminary...

I agree with @alexhultman, I think this is something we should fix in WebAssembly rather than requesting various web APIs to provide a view. Another problem with that solution is...

> If the API is currently producing an ArrayBuffer, then there's already an inherent copy going on Yes, I suppose so. Though it's possible that the API is providing direct...