Can feature names be reframed as parameters?

[lukewagner]

I liked the reframing of this proposal in today's CG call as conditional compilation/inclusion, as opposed to feature-detection. However, iiuc, conditional expressions still bottom out in a feature-name string, so there is still the essential question: how is the set of feature-names defined?

In particular, I think there is one hard question that has bad outcomes with either answer: are browsers allowed to include ad hoc (not in some formal standard) feature strings?

• If "yes": this will lead to vendor-specific feature names which will, in the fullness of time, likely play out like CSS vendor prefixes which browsers all agreed was, in retrospect, not a good idea.
• If "no": then the granularity of feature testing may end up being too low (e.g., it has already been the case several times that a feature is deployed/released incrementally), so this feature doesn't end up solving the problem it was created to solve.

What if instead:

• feature names were recast as "parameter names", with no a priori defined meaning
• it was up to the host (e.g., using WebAssembly.validate() and other ad hoc probing methods) to answer the atomic question: "is feature X, for my definition of X, supported in this host?", ultimately passing that bool as the value for a parameter name at compile-time.

With this style of design:

• no wasm or other standard needs to bake in for all time a list of "features" which are ultimately cruft, once widely implemented
• conditional inclusion wouldn't be limited to just wasm feature availability but also questions like:
  • is navigator.hardwareConcurrency > 1?
  • are COOP and COEP set?
  • is (non-wasm) Web API X impemented?

I'm not sure what the exact right API design is for this. One obvious idea is that WebAssembly.compile() (and other APIs that compile from bytecode to a Module) could take a (parameter,value) list, feeding those values into the conditions when compiling the module.

[tlively]

Thanks for raising this question. I think it gets to the point that this proposal currently serves two related purposes. First, this proposal provides a feature detection mechanism, and second, this proposal provides a general mechanism for conditional compilation based on arbitrary Boolean formulae. As written, the formulae are restricted to only use feature strings, but there is strong interest (#6) in generalizing that as you suggest.

Essentially you are proposing that we remove the feature detection mechanism from the proposal and double down on the conditional section mechanism. In principle this is something we could do, but then there would be no specified mechanism of feature detection inside wasm. In the web context we can always fall back to feature probing or a JS API, as proposed in #7, but in pure-wasm environments like WASI there would be no way to do feature detection.

I actually like your suggestion, though, because it avoids baking magical strings into the core WebAssembly spec. One possible solution would be to specify the feature strings elsewhere, such as in the tool-conventions or WASI repos. WASI engines would have to provide the feature strings themselves and Emscripten and other web-targeting toolchains would have to do their own feature detection to pass in the correct feature strings, but that would not need to be coordinated via the core WebAssembly spec. @rossberg, @sunfishcode, and @kripken what are your thoughts on this?

[rossberg]

@tlively:
Makes sense to me. Tools conventions would be an appropriate place I suppose.

@lukewagner:

other APIs that compile from bytecode to a Module) could take a (parameter,value) list, feeding those values into the conditions when compiling the module.

A string list would suffice, since the feature flags are just names that are either defined (true) or not (false), but don't have a value other than that. That's good, because it avoids a can of worms of arithmetic operators in formulae.

[kripken]

@tlively @lukewagner sgtm, and tool-conventions seems like a reasonable place for that. I do think WebAssembly/feature-detection#7 (a JS API for feature detection) would be nice but I understand that is nicely separated out from the topic of conditional compilation.

[sunfishcode]

tool-conventions would be a little awkward for WASI, because this is something that WASI environments would need to implement to run WASI programs, and a future WASI standard document wouldn't want to depend on a tool-conventions document (wasi-sdk does use some things from tool-conventions, but it's just a tool so it can do that :-)).

Would it make sense for WASI to standardize the features it needs for itself?

[tlively]

Since WASI is a more "official" standard than tool conventions, I would be happy to have the feature strings be standardized there. We would want to pull relevant strings into the tool-conventions repo as well, though. I could imagine WASI defining strings for both wasm architecture features and other things like the presence of different WASI APIs, and tool-conventions would only want the former.

[kripken]

Yeah, WASI and tool-conventions can mirror each other for these feature strings, as we probably don't want either to depend on the other.

[binji]

Chiming in late to say I like this too. That said, it seems like it is more likely to get us toward the case that @lukewagner described at the top:

If "yes": this will lead to vendor-specific feature names which will, in the fullness of time, likely play out like CSS vendor prefixes which browsers all agreed was, in retrospect, not a good idea.

[tlively]

@binji With @lukewagner's suggestion, the browser does not pass any feature strings itself, so differences in feature strings would only come from different toolchains following different conventions. Is that what you're worried about?

[binji]

The main suggestion here is decoupling the names from an existing feature proposal, right? It seems like this will make it easier to include arbitrary "features" in the wasm binary.

[tlively]

Yes, but the features are under the control of the users and their tools rather than the browser vendors, so this seems different from CSS vendor prefixes. IIUC, the CSS vendor prefixes were bad because they were a source of incompatibility between browsers, but with the proposal any feature would work on any browser.

[binji]

I guess I don't see how it's significantly different. It's still the case that a wasm host must say "yes, I support this name" or "no, I don't". So the wasm host can still advertise, "yes, I support vendor-non-standard-feature".