How should features be specified?

[tlively]

The purpose of this proposal is to allow modules to validate even when they conditionally use instructions not supported by the engine, but the spec so far has no concept of optional or unsupported instructions. All instructions are currently either mandatory or do not exist as far as the spec is concerned.

One solution would be to avoid adding a concept of features to the normative spec, to specify features.supported and feature_block as succeeding if the feature bitvector is a particular constant and failing otherwise, and relying on non-normative text to document what each feature actually means. This is not a very satisfying solution because we want feature detection to be as well-specified and portable as any other part of WebAssembly.

A better option would be to add a notion of features to the spec, tag (every?) instruction with the feature(s?) it belongs to, and explicitly allow implementations to choose whether or not to support each feature. The spec would essentially be parameterized by the supported features.

Are there any problems with that approach? Are there better alternatives? @rossberg, I'd be particularly interested in your thoughts here.

[rossberg]

In the context of the "profiles" proposal (which I still have to write up), the idea was that we can mark certain grammar productions and semantic rules with tags representing features. This would be set up such that only those that are optional in one way or another have to be tagged, not every production or rule.

However, this could get out of hand very quickly if we intended to introduce overly fine-grained features, as seems to be the intention of this proposal.

(But non-normative text would be a complete cop-out that undermine our claims for precise specification.)

[tlively]

Ok, great, tagging grammar productions is essentially what I had in mind, I think. I would actually like not to have fine-grained features, so that should work well.