WebAssembly / component-model

Repository for design and specification of the Component Model
Other
947 stars 79 forks source link

Consider re-allowing import/export kebab-names to overlap #252

Closed lukewagner closed 1 year ago

lukewagner commented 1 year ago

Earlier, we tightened the rules for import/export names to disallow them from having the same name. The motivation was to avoid requiring bindings generators to have to conservatively group imports and exports into separate namespaces and also to allow the body of a world to refer to either an import or export with a simple identifier without the need to qualify "import" or "export".

Since then, however, a few things have developed that suggest revisiting this restriction:

  1. From what I've seen of bindings generators, import and export names end up being put in separate namespaces anyways.
  2. We're using use to project resource types from imported interface, not dotted id.foo projections.
  3. We split import/export names into bare kebab-names and interface ids and, because we have clear use cases for it, we allow the same interface id to be imported and exported.

Thus, it's both a bit irregular not to be able to import/export the same kebab-name and also it doesn't seem to be buying us much in practice (afaik, but happy to hear otherwise). Thus, I think it makes sense to ask whether we should remove this restriction for kebab-names (so that kebab-name rules matched interface id rules).

@esoterra hit this restriction organically while working on his WasmCon demo, and, at least in that context, the restriction does feel artificial and credit to Kyle for raising the question.

esoterra commented 1 year ago

To elaborate on the use case, I needed a simple proxy world that imported and exported a greet function. The interfaces and source code implementations for the demo are available in a GitHub repo.

While this specific use case is quite trivial, I expect I'm not the only person who will want to make simple proxy components and it's pretty surprising and frustrating to have to add extra indirection through an interface to get around this rule.

To provide more support for the first point Luke made, each of the different example components distinguished the names or namespaces of imports and exports anyway. Here's a quick overview of what that looked like for each of the four languages.

Thanks for officially proposing this Luke!

lukewagner commented 1 year ago

Seems like no problems with the change, so I filed #259 to make the change.