Allow the generation of Swift code that follows the normal case conventions.

[pixlwave]

Semi-related to #1426, it would be great if UniFFI could generate Swift function/variable/argument/type names that conform to the “Follow case conventions” point in the Swift API Design Guidelines:

Acronyms and initialisms that commonly appear as all upper case in American English should be uniformly up- or down-cased according to case conventions.

A couple of examples:

Rust	Swift (current)	Swift (desirable)
avatar_url	avatarUrl	avatarURL
raw_json_string	rawJsonString	rawJSONString

Some obvious thoughts that came out of an initial conversation:

• This should be opt-in to avoid breaking backwards compatibility.
• The set of acronyms/initialisms should probably be defined by each project in their uniffi.toml as whilst some conversions like URL and JSON aren't debatable, other such as ID may raise discussion as to whether or not they count (and this clearly isn't UniFFI's problem to deal with).
  • This could also make incremental adoption easy as a project could migrate acronym by acronym.

[mhammond]

Also related to #2262.

IMO those guidelines are odd, subjective and depend so much on context - you mention ID but I doubt it would be difficult to find people who swear they use Url or url instead of URL (and we work for a browser company :) For that and other reasons, I doubt uniffi would ever ship with a default acronym list. Further, things get a little more complicated when considering things like argument names. Would we end up with multiple lists, each for different contexts?

Which makes we wonder if a list even makes sense - it might not be clear exactly when this list is supposed to be consulted (and that may itself be subjective). So why not just have #1426 (and maybe companions for, say argument names etc)? It's one less level of indirection which might cause a small amount of duplication (eg, you'd need to list both getJSON and setJSON) but might be clearer and offers more control (ie, you get to say exactly what the identifier is called, not just control individual parts of it)

[pixlwave]

I doubt it would be difficult to find people who swear they use Url or url instead of URL

I'm not sure I would agree here given skimming through the documentation for URL and NSURL (plus related types like URLComponents, URLRequest, URLSession etc) should make it pretty obvious how unusual Url would be for a Swift/Objective-C developer. (url is perfectly acceptable based on the guidelines if it's at the start of a function/variable/argument e.g. urlString).

For that and other reasons, I doubt uniffi would ever ship with a default acronym list.

Agreed, this should be defined by each project.

Further, things get a little more complicated when considering things like argument names. Would we end up with multiple lists, each for different contexts?

I don't think so, the conventions are applied everywhere e.g. loadSimulatedRequest(_:responseHTML:). I've added arguments to the initial comment as I see they were missing.

Which makes we wonder if a list even makes sense - it might not be clear exactly when this list is supposed to be consulted (and that may itself be subjective). So why not just have #1426 (and maybe companions for, say argument names etc)? It's one less level of indirection which might cause a small amount of duplication (eg, you'd need to list both getJSON and setJSON) but might be clearer and offers more control (ie, you get to say exactly what the identifier is called, not just control individual parts of it)

#1426 would definitely help, but would have the following drawbacks:

• It puts the onus on Rust developers to know and remember how Swift developers prefer the generated output to look like each time they expose something through the FFI.
• Taking a project whose authors are using UniFFI for just e.g. Kotlin: To build that project for Swift with the expected output would essentially require forking the project and refining the interface manually. Whereas with this proposal a tiny amount of configuration in a single file would have a huge impact on the output and could be automated as part of the build step without needing a fork.
• Generally, it can become pretty tedious to have to refine the same thing over and over when a pattern exists that an algorithm could follow and it becomes easy to miss something resulting in a mixed output style.