Skip to content

Fix WIT.md example #493

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Apr 8, 2025
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
9 changes: 2 additions & 7 deletions design/mvp/WIT.md
Original file line number Diff line number Diff line change
Expand Up @@ -947,7 +947,7 @@ interface foo {
@since(version = 0.2.1)
b: func();

@since(version = 0.2.2, feature = fancy-foo)
@since(version = 0.2.2)
c: func();

@unstable(feature = fancier-foo)
Expand All @@ -973,19 +973,14 @@ default unless explicitly opted-into by the developer.

Finally, the `@deprecated` gate on `e` indicates that `e` should no longer be
used starting version `0.2.2`. Both toolchains and host runtimes may warn users
if they detect an `@deprecated` API is being used. An `@deprecated` gate is
if they detect an `@deprecated` API is being used. A `@deprecated` gate is
required to always be paired up with either a `@since` or `@deprecated` gate.

Together, these gates support a development flow in which new features start
with an `@unstable` gate while the details are still being hashed out. Then,
once the feature is stable (and, in a WASI context, voted upon), the
`@unstable` gate is switched to a `@since` gate.

Thus, `c` is enabled if the version is `0.2.2` or newer or the
`fancy-foo` feature is explicitly enabled by the developer. The `feature` field
can be removed once producer toolchains have updated their default version to
enable the feature by default.

#### Feature gate syntax

The grammar that governs feature gate syntax is:
Expand Down