Andreas Rossberg

Nice! As @RossTate points out, this looks similar to the private types in the type import proposal, except that that treats private types as reference types, in order to allow...

On 4 September 2017 at 03:42, Pauan wrote: > > JavaScript already competes with other languages. WebAssembly just makes > other languages more efficient, that's all. > The latter is...

@unmellow, to debunk that myth again: there would be no magic performance gains from compiling JS to Wasm, quite the contrary. If you want better performance than JS engines are...

> I suppose endianness could in some sense be an attribute of the memory object Endianness isn't limited to memory instructions, though. Another example are the reinterpret instructions. And then...

The spec [mentions](https://webassembly.github.io/spec/core/exec/runtime.html#addresses) this. It is unfortunate, but generally seems unavoidable, given the interop constraints. What alternative would you suggest?

Hm, "every time" would mean an allocation on every JS-side access to a table, or a function global, or a higher-order call. Besides the cost, wouldn't it be semantically dubious...

> 1. If `funcref` has exposed identity in JS, and it's a subtype of `anyref` (should we add it back), then should `anyref` also have exposed identity in JS? The...

@RossTate: > Even if it's a minority, not having identity for that minority can be hugely useful. Agreed in the abstract, yet such a hypothetical would need somewhat more concrete...

Hm, yes, but there isn't necessarily a domain associated with everything, at least not a canonical one, or the domain may change over time. It would also be rather verbose....

I believe we even discussed this in the early days. IIRC, the argument was that for functions, this is meant to support parallel decoding/compilation, and that isn't really useful for...