wit: Propagate feature gate annotations to inner items

[lann]

I think that these two snippets should be equivalent:

@since(version = 0.1.0)
interface handler {
  handle: func();

  @since(version = 0.2.0);
  new-handle: func();
}

@since(version = 0.1.0)
interface new-interface {
  @since(version = 0.1.0)
  hello: func();

  @since(version = 0.2.0);
  new-handle: func();
}

The more explicit version would be the canonical form reflected in the parse tree.

I think this goes beyond just authoring convenience. When every item is annotated it becomes more difficult to pick out the exceptional items; see e.g. https://github.com/WebAssembly/wasi-http/blob/main/wit/types.wit

[pchickey]

Agreed, I've struggled to read this in the past.

[lukewagner]

Sounds good to me too. cc @yoshuawuyts for any other thoughts

[alexcrichton]

The original rationale for this was to match the behavior of Rust where the consequences of accidentally stabilizing something were quite high. Those exact motivations aren't as applicable to WIT so I think it'd be reasonable to deviate from the design. To be clear, though, this means that adding a new function inside a stable interface is, by default, a stable function. Authors have to proactively reach for @unstable to mark it as a non-stable API.

Personally I would hope that there's so few users of @since (just WASI specs in theory) that we could maintain the verbose-ness and "you must write something down" behavior. I'd be ok acquiescing to a different direction though as I don't feel particularly strongly about this.

[tschneidereit]

This relates to something we've talked about at various previous points: we should have semver checking tools for WIT. Those would be useful independently, but would also effectively avoid the issue @alexcrichton raises: before any versions of an interface are officially published, there's nothing to worry about. And if there's a previous version, it's never valid to add a new item in a new version without declaring which version it was introduced at.

("effectively avoid" only if said tooling is used in practice, of course. But at least for WASI we could automate this, as could registries.)