Skip to content

wit: Propagate feature gate annotations to inner items #559

Open

Description

@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

Activity

  1. pchickey commented on Aug 29, 2025

    @pchickey

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

  2. lukewagner commented on Aug 29, 2025

    @lukewagner
    Member

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

  3. alexcrichton commented on Sep 2, 2025

    @alexcrichton
    Collaborator

    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.

  4. tschneidereit commented on Sep 2, 2025

    @tschneidereit
    Member

    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.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions