You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
wit: Propagate feature gate annotations to inner items #559
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.
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.)
Activity
pchickey commentedon Aug 29, 2025
Agreed, I've struggled to read this in the past.
lukewagner commentedon Aug 29, 2025
Sounds good to me too. cc @yoshuawuyts for any other thoughts
alexcrichton commentedon Sep 2, 2025
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
@unstableto 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 commentedon Sep 2, 2025
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.)