Skip to content
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

wit: Disallow duplicate names between types and functions #835

Closed
peterhuene opened this issue Feb 26, 2022 · 3 comments
Closed

wit: Disallow duplicate names between types and functions #835

peterhuene opened this issue Feb 26, 2022 · 3 comments
Labels
wit related to the `*.wit` text format

Comments

@peterhuene
Copy link
Member

Currently in wit, this is legal:

record foo {
}

foo: function(f: foo)

In the current component mode proposal, exports are used to name things, so a component with this interface would export a record interface type named foo and a function type named foo. As duplicate exports are illegal in WebAssembly components, this would fail validation.

Another reason to not allow this is that some language bindings might use a similar naming convention between type identifiers and function identifiers and such a binding generator would need to use an alternative (potentially unwieldy) name to prevent a collision

@esoterra
Copy link
Contributor

Should names be unique across functions, resources, and types?
I'm working on a draft implementation and all three are handled separately at the moment.

@alexcrichton
Copy link
Member

I think to accomodate the broadest variety of languages we'll be generating bindings into it's probably best to have everything in the same namespace and forbid any clashes.

@alexcrichton alexcrichton transferred this issue from bytecodealliance/wit-bindgen Nov 22, 2022
@alexcrichton alexcrichton changed the title Disallow duplicate names between types and functions wit: Disallow duplicate names between types and functions Nov 22, 2022
@alexcrichton alexcrichton added the wit related to the `*.wit` text format label Nov 22, 2022
@alexcrichton
Copy link
Member

done in #867

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
wit related to the `*.wit` text format
Projects
None yet
Development

No branches or pull requests

3 participants