@@ -33,6 +33,7 @@ more user-focused explanation, take a look at the
3333 * [ Start definitions] ( #-start-definitions )
3434 * [ Import and export definitions] ( #import-and-export-definitions )
3535 * [ Name uniqueness] ( #name-uniqueness )
36+ * [ Canonical interface name] ( #canonical-interface-name )
3637* [ Component invariants] ( #component-invariants )
3738* [ JavaScript embedding] ( #JavaScript-embedding )
3839 * [ JS API] ( #JS-API )
@@ -294,7 +295,7 @@ sort ::= core <core:sort>
294295 | type
295296 | component
296297 | instance
297- inlineexport ::= (export <exportname> <sortidx>)
298+ inlineexport ::= (export " <exportname>" <versionsuffix>? <sortidx>)
298299```
299300Because component-level function, type and instance definitions are different
300301than core-level function, type and instance definitions, they are put into
@@ -574,8 +575,8 @@ instancedecl ::= core-prefix(<core:type>)
574575 | <alias>
575576 | <exportdecl>
576577 | <value> 🪙
577- importdecl ::= (import <importname> bind-id(<externdesc>))
578- exportdecl ::= (export <exportname> bind-id(<externdesc>))
578+ importdecl ::= (import " <importname>" <versionsuffix>? bind-id(<externdesc>))
579+ exportdecl ::= (export " <exportname>" <versionsuffix>? bind-id(<externdesc>))
579580externdesc ::= (<sort> (type <u32>) )
580581 | core-prefix(<core:moduletype>)
581582 | <functype>
@@ -2242,8 +2243,9 @@ the identifier `$x`). In the case of exports, the `<id>?` right after the
22422243preceding definition being exported (e.g., ` (export $x "x" (func $f)) ` binds a
22432244new identifier ` $x ` ).
22442245``` ebnf
2245- import ::= (import "<importname>" bind-id(<externdesc>))
2246- export ::= (export <id>? "<exportname>" <sortidx> <externdesc>?)
2246+ import ::= (import "<importname>" <versionsuffix>? bind-id(<externdesc>))
2247+ export ::= (export <id>? "<exportname>" <versionsuffix>? <sortidx> <externdesc>?)
2248+ versionsuffix ::= (versionsuffix "<semversuffix>")
22472249```
22482250All import names are required to be [ strongly-unique] . Separately, all export
22492251names are also required to be [ strongly-unique] . The rest of the grammar for
@@ -2276,17 +2278,24 @@ fragment ::= <word>
22762278 | <acronym>
22772279word ::= [a-z] [0-9a-z]*
22782280acronym ::= [A-Z] [0-9A-Z]*
2279- interfacename ::= <namespace> <label> <projection> <version >?
2280- | <namespace>+ <label> <projection>+ <version >? 🪺
2281+ interfacename ::= <namespace> <label> <projection> <interfaceversion >?
2282+ | <namespace>+ <label> <projection>+ <interfaceversion >? 🪺
22812283namespace ::= <words> ':'
22822284words ::= <word>
22832285 | <words> '-' <word>
22842286projection ::= '/' <label>
2285- version ::= '@' <valid semver>
2287+ # FIXME: surrounding alignment
2288+ interfaceversion ::= '@' <valid semver>
2289+ | '@' <canonversion>
2290+ canonversion ::= [1-9] [0-9]*
2291+ | '0.' [1-9] [0-9]*
2292+ | '0.0.' [1-9] [0-9]*
2293+ semversuffix ::= [.+-][0-9A-Za-z.+-]+
22862294depname ::= 'unlocked-dep=<' <pkgnamequery> '>'
22872295 | 'locked-dep=<' <pkgname> '>' ( ',' <hashname> )?
22882296pkgnamequery ::= <pkgpath> <verrange>?
2289- pkgname ::= <pkgpath> <version>?
2297+ pkgname ::= <pkgpath> <pkgversion>?
2298+ pkgversion ::= '@' <valid semver>
22902299pkgpath ::= <namespace> <words>
22912300 | <namespace>+ <words> <projection>* 🪺
22922301verrange ::= '@*'
@@ -2372,12 +2381,14 @@ tooling as "registries":
23722381 parameter of [ ` WebAssembly.instantiate() ` ] )
23732382
23742383The ` valid semver ` production is as defined by the [ Semantic Versioning 2.0]
2375- spec and is meant to be interpreted according to that specification. The
2376- ` verrange ` production embeds a minimal subset of the syntax for version ranges
2377- found in common package managers like ` npm ` and ` cargo ` and is meant to be
2378- interpreted with the same [ semantics] [ SemVerRange ] . (Mostly this
2379- interpretation is the usual SemVer-spec-defined ordering, but note the
2380- particular behavior of pre-release tags.)
2384+ spec and is meant to be interpreted according to that specification. The use of
2385+ ` valid semver ` in ` interfaceversion ` is temporary for backward compatibility;
2386+ see [ Canonical interface name] ( #canonical-interface-name ) below. The ` verrange `
2387+ production embeds a minimal subset of the syntax for version ranges found in
2388+ common package managers like ` npm ` and ` cargo ` and is meant to be interpreted
2389+ with the same [ semantics] [ SemVerRange ] . (Mostly this interpretation is the usual
2390+ SemVer-spec-defined ordering, but note the particular behavior of pre-release
2391+ tags.)
23812392
23822393The ` plainname ` production captures several language-neutral syntactic hints
23832394that allow bindings generators to produce more idiomatic bindings in their
@@ -2539,6 +2550,49 @@ annotations. For example, the validation rules for `[constructor]foo` require
25392550for details.
25402551
25412552
2553+ ### Canonical Interface Name
2554+
2555+ An ` interfacename ` (as defined above) is ** canonical** iff it either:
2556+
2557+ - has no ` interfaceversion `
2558+ - has an ` interfaceversion ` matching the ` canonversion ` production
2559+
2560+ The purpose of ` canonversion ` is to simplify the matching of compatible import
2561+ and export versions. For example, if a guest imports some interface from
2562+ ` wasi:http/[email protected] ` and a host provides the (subtype-compatible) interface
2563+ ` wasi:http/[email protected] ` , we'd like to make it easy for the host to link with the
2564+ guest. The ` canonversion ` for both of these interfaces would be ` 0.2 ` , so this
2565+ linking could be done by matching canonical interface names literally.
2566+ Symmetrically, if a host provides
` wasi:http/[email protected] ` and a guest imports
2567+ ` wasi:http/[email protected] ` , so long as the guest's imported
` instancetype ` is
2568+ subtype-compatible with the host implementation linking should be trivial.
2569+
2570+ Any ` valid semver ` (as used in WIT) can be canonicalized by splitting it into
2571+ two parts - the ` canonversion ` prefix and the remaining ` semversuffix ` . Using
2572+ the ` <major>.<minor>.<patch> ` syntax of [ Semantic Versioning 2.0] , the split
2573+ point is chosen as follows:
2574+
2575+ - if ` major ` > 0, split immediately after ` major `
2576+ - ` 1.2.3 ` &rarr ; ` 1 ` / ` .2.3 `
2577+ - otherwise if ` minor ` > 0, split immediately after ` minor `
2578+ - ` 0.2.6-rc.1 ` &rarr ; ` 0.2 ` / ` .6-rc.1 `
2579+ - otherwise, split immediately after ` patch `
2580+ - ` 0.0.1-alpha ` &rarr ; ` 0.0.1 ` / ` -alpha `
2581+
2582+ When a version is canonicalized, any ` semversuffix ` that was split off of the
2583+ version should be preserved in the ` versionsuffix ` field of any resulting
2584+ ` import ` s and ` export ` s. This gives component runtimes and other tools access to
2585+ the original version for error messages, documentation, and other development
2586+ purposes. Where a ` versionsuffix ` is present the preceding ` interfacename ` must
2587+ have a ` canonversion ` , and the concatenation of the ` canonversion ` and
2588+ ` versionsuffix ` must be a ` valid semver ` .
2589+
2590+ For compatibility with older versions of this spec, non-canonical
2591+ ` interfacename ` s (with ` interfaceversion ` s matching any ` valid semver ` ) are
2592+ temporarily permitted. These non-canonical names may trigger warnings and will
2593+ start being rejected some time after after [ WASI Preview 3] is released.
2594+
2595+
25422596## Component Invariants
25432597
25442598As a consequence of the shared-nothing design described above, all calls into
@@ -2894,6 +2948,7 @@ For some use-case-focused, worked examples, see:
28942948[ `rectype` ] : https://webassembly.github.io/gc/core/text/types.html#text-rectype
28952949[ shared-everything-threads ] : https://github.com/WebAssembly/shared-everything-threads
28962950[ WASI Preview 2 ] : https://github.com/WebAssembly/WASI/tree/main/wasip2#readme
2951+ [ WASI Preview 3 ] : https://github.com/WebAssembly/WASI/tree/main/wasip2#looking-forward-to-preview-3
28972952[ reference types ] : https://github.com/WebAssembly/reference-types/blob/master/proposals/reference-types/Overview.md
28982953
28992954[ Strongly-unique ] : #name-uniqueness
0 commit comments