Open dcodeIO opened 5 years ago
There seem to be two reasonable approaches here:
Both of these seem bad. Perhaps a middle ground would be to keep MVP as the default, but bundle features into "releases" so users could target "wasm2020" or something without having to know the details. We would still need a centralized caniwasm.com sort of thing to document what features or releases each engine supports, though.
In a recent Binaryen PR the question of when to enable post-MVP features in tooling came up. In particular, since the mutable-global proposal had been finished meanwhile, the suggestion there was to enable the feature by default in Binaryen (and have a
Default
feature set to target finished features). On the AssemblyScript side, a good strategy seems to be to enable finished proposals by default as soon as our toolchain supports them in a stable manner, closely aligning with the standardization process. Until there is some sort of feature detection this also means: If a targeted engine supports more than the finished proposals, those must be explicitly enabled in tooling. Likewise, if a targeted engine supports less than the finished proposals, those must be explicitly disabled in tooling.As suggested by @kripken I'm opening this issue so we can coordinate.