Define and require names to be 'strongly-unique'

Author: lukewagner

design/mvp/Binary.md

@@ -270,8 +270,7 @@ Notes:
 * All parameter labels, result labels, record field labels, variant case
   labels, flag labels, enum case labels, component import names, component
   export names, instance import names and instance export names must be
-  unique in their containing scope, considering two labels that differ only in
-  case to be equal and thus rejected.
+  [strongly-unique] in their containing scope.
 * Validation of `externdesc` requires the various `typeidx` type constructors
   to match the preceding `sort`.
 * (The `0x00` immediate of `case` may be reinterpreted in the future as the
@@ -386,8 +385,8 @@ Notes:
   of the inferred `externdesc` of the `sortidx`.
 * `<importname>` and `<exportname>` refer to the productions defined in the
   [text format](Explainer.md#import-and-export-definitions).
-* The `<importname>`s of a component must be unique and the `<exportname>`s of
-  a component must be unique as well (defined in terms of raw string equality).
+* The `<importname>`s of a component must all be [strongly-unique]. Separately,
+  the `<exportname>`s of a component must also all be [strongly-unique].
 * Validation requires that annotated `plainname`s only occur on `func` imports
   or exports and that the first label of a `[constructor]`, `[method]` or
   `[static]` matches the `plainname` of a preceding `resource` import or
@@ -397,8 +396,6 @@ Notes:
   `(result (own $R))`, where `$R` is the resource labeled `r`.
 * Validation of `[method]` names requires the first parameter of the function
   to be `(param "self" (borrow $R))`, where `$R` is the resource labeled `r`.
-* Validation of `[method]` and `[static]` names ensures that all field names
-  are disjoint.
 * `<valid semver>` is as defined by [https://semver.org](https://semver.org/)
 * `<integrity-metadata>` is as defined by the
   [SRI](https://www.w3.org/TR/SRI/#dfn-integrity-metadata) spec.
@@ -517,6 +514,8 @@ named once.
 [`core:functype`]: https://webassembly.github.io/spec/core/binary/types.html#binary-functype
 [`core:rectype]: https://webassembly.github.io/gc/core/binary/types.html#recursive-types
 
+[Strongly-unique]: Explainer.md#name-uniqueness
+
 [type-imports]: https://github.com/WebAssembly/proposal-type-imports/blob/master/proposals/type-imports/Overview.md
 [module-linking]: https://github.com/WebAssembly/module-linking/blob/main/proposals/module-linking/Explainer.md
 

design/mvp/Explainer.md

@@ -32,6 +32,7 @@ more user-focused explanation, take a look at the
   * [Value definitions](#-value-definitions)
   * [Start definitions](#-start-definitions)
   * [Import and export definitions](#import-and-export-definitions)
+    * [Name uniqueness](#name-uniqueness)
 * [Component invariants](#component-invariants)
 * [JavaScript embedding](#JavaScript-embedding)
   * [JS API](#JS-API)
@@ -782,8 +783,8 @@ The remaining 4 type constructors in `deftype` use `valtype` to describe
 shared-nothing functions, resources, components, and component instances:
 
 The `func` type constructor describes a component-level function definition
-that takes a list of uniquely-named `valtype` parameters and optionally returns
-a `valtype`.
+that takes a list of `valtype` parameters with [strongly-unique] names and
+optionally returns a `valtype`.
 
 The `resource` type constructor creates a fresh type for each instance of the
 containing component (with "freshness" and its interaction with general
@@ -2191,16 +2192,17 @@ new identifier `$x`).
 import ::= (import "<importname>" bind-id(<externdesc>))
 export ::= (export <id>? "<exportname>" <sortidx> <externdesc>?)
 ```
-All import names are required to be unique and all export names are required to
-be unique. The rest of the grammar for imports and exports defines a structured
-syntax for the contents of import and export names. Syntactically, these names
-appear inside quoted string literals. The grammar thus restricts the contents
-of these string literals to provide more structured information that can be
-mechanically interpreted by toolchains and runtimes to support idiomatic
-developer workflows and source-language bindings. The rules defining this
-structured name syntax below are to be interpreted as a *lexical* grammar
-defining a single token and thus whitespace is not automatically inserted, all
-terminals are single-quoted, and everything unquoted is a meta-character.
+All import names are required to be [strongly-unique]. Separately, all export
+names are also required to be [strongly-unique]. The rest of the grammar for
+imports and exports defines a structured syntax for the contents of import and
+export names. Syntactically, these names appear inside quoted string literals.
+The grammar thus restricts the contents of these string literals to provide
+more structured information that can be mechanically interpreted by toolchains
+and runtimes to support idiomatic developer workflows and source-language
+bindings. The rules defining this structured name syntax below are to be
+interpreted as a *lexical* grammar defining a single token and thus whitespace
+is not automatically inserted, all terminals are single-quoted, and everything
+unquoted is a meta-character.
 ```ebnf
 exportname    ::= <plainname>
                 | <interfacename>
@@ -2358,12 +2360,6 @@ mapped to `isXML`, `IsXml`, `is_XML` or `is_xml`, depending on the target
 language/convention. The highly-restricted character set ensures that
 capitalization is trivial and does not require consulting Unicode tables.
 
-Because some casing schemes (such as all-lowercase) would lead to clashes if
-two `label`s differed only in case, in all cases where "uniqueness" is required
-between a set of names (viz., import/export names, record field labels, variant
-case labels, and function parameter/result names), two `label`s that differ
-only in case are considered equal and thus rejected.
-
 Components provide two options for naming exports, symmetric to the first two
 options for naming imports:
 * a **plain name** that leaves it up to the developer to "read the docs"
@@ -2455,6 +2451,39 @@ The inferred type of this component is:
 
 Note, that the `url` value definition is absent from the component type
 
+### Name Uniqueness
+
+The goal of the `label`, `exportname` and `importname` productions defined and
+used above is to allow automated bindings generators to map these names into
+something more idiomatic to the language. For example, the `plainname`
+`[method]my-resource.my-method` might get mapped to a method named `myMethod`
+nested inside a class `MyResource`. To unburden bindings generators from having
+to consider pathological cases where two unique-in-the-component names get
+mapped to the same source-language identifier, Component Model validation
+imposes a stronger form of uniquness than simple string equality on all the
+names that appear within the same scope.
+
+To determine whether two names (defined as sequences of [Unicode Scalar
+Values]) are **strongly-unique**:
+* If one name is `l` and the other name is `[constructor]l` (for the same
+  `label` `l`), they are strongly-unique.
+* Otherwise:
+  * Lowercase all the `acronym`s (uppercase letters) in both names.
+  * Strip any `[...]` annotation prefix from both names.
+  * The names are strongly-unique if the resulting strings are unequal.
+
+Thus, the following names are strongly-unique:
+* `foo`, `foo-bar`, `[constructor]foo`, `[method]foo.bar`, `[method]foo.baz`
+
+but attempting to add *any* of the following names would be a validation error:
+* `foo`, `foo-BAR`, `[constructor]foo-BAR`, `[async]foo`, `[method]foo.BAR`
+
+Note that additional validation rules involving types apply to names with
+annotations. For example, the validation rules for `[constructor]foo` require
+`foo` to be a resource type. See [Binary.md](Binary.md#import-and-export-definitions)
+for details.
+
+
 ## Component Invariants
 
 As a consequence of the shared-nothing design described above, all calls into
@@ -2812,6 +2841,8 @@ For some use-case-focused, worked examples, see:
 [WASI Preview 2]: https://github.com/WebAssembly/WASI/tree/main/wasip2#readme
 [reference types]: https://github.com/WebAssembly/reference-types/blob/master/proposals/reference-types/Overview.md
 
+[Strongly-unique]: #name-uniqueness
+
 [Adapter Functions]: FutureFeatures.md#custom-abis-via-adapter-functions
 [Canonical ABI explainer]: CanonicalABI.md
 [`canon_context_get`]: CanonicalABI.md#-canon-contextget