Kebab-case definition produces collision when mapped to snake_case

[sunfishcode]

The component-model grammar has this for <name>:

name           ::= <word>
                 | <name>-<word>
word           ::= [a-z][0-9a-z]*
                 | [A-Z][0-9A-Z]*

That accepts both "apple" and "APPLE". This leads to collisions when converting to snake_case for languages which use that convention.

[lukewagner]

Great point! So I suppose what we need to do here is tighten up the uniqueness condition to be case insensitive, so that you could have one or the other but not both.

[tschneidereit]

Treating identifiers as case-insensitive is what we'd talked about in the past precisely to avoid this issue.

I guess the main question is if we allow lower- and upper-case and treat identifiers as case-insensitive, or we enforce all-lower-case. The latter might be better, because it makes for cheaper and purely local validation, instead of multiple identifiers influencing each other.

[lukewagner]

All-upper-case words are allowed in kebab-names to indicate that the word is an acronym, which the language casing scheme may treat differently than normal words. I think, in either case, the uniqueness condition is equally local, since you have to build a set of all names in the scope (imports or exports) to detect dupes.

[tschneidereit]

All-upper-case words are allowed in kebab-names to indicate that the word is an acronym, which the language casing scheme may treat differently than normal words.

Ok, that's fair. We had in the past concluded that we'd not cover that case and require e.g. HttpRequest instead of HTTPRequest, but I see how people might feel strongly about enabling the latter. It does lead to strictly better bindings at no further cost, too, I suppose, since you're right about thee locality being the same, yeah.

[sunfishcode]

I opened bytecodealliance/wit-bindgen#385 with a prototype implementation of this.