Hi, everyone. Today in the API Design Guidelines 
<https://swift.org/documentation/api-design-guidelines/> we have this section 
on case:

> Follow case conventions. Names of types and protocols are UpperCamelCase. 
> Everything else is lowerCamelCase.
> 
> Acronyms and initialisms that commonly appear as all upper case in American 
> English should be uniformly up- or down-cased according to case conventions:
> 
> var utf8Bytes: [UTF8.CodeUnit]
> var isRepresentableAsASCII = true
> var userSMTPServer: SecureSMTPServer
> 
> Other acronyms should be treated as ordinary words:
> 
> var radarDetector: RadarScanner
> var enjoysScubaDiving = true

However, this doesn't directly address words that are conventionally written 
with mixed case. Usually these are names, such as "iPad", "LaTeX", or “NeXT”, 
but sometimes they’re just acronyms or initialisms with very strong 
conventions, like “NaN”. (Yes, the FloatingPoint proposal is what prompted this 
whole thing.)

There are a few options for what we could do with these words to make them 
consistent with our existing rules for words that are all-uppercase, 
all-lowercase, or capitalized (first letter uppercase, remaining letters 
lowercase). It’s pretty clear from the “utf8Bytes” example above that use at 
the start of a “lowerCamelCase” identifier means uniformly downcasing all of 
the letters: “ipad”, “latex”, “next”, “nan”. However, it’s unclear exactly what 
operation is being applied to subsequent words in an identifier:

Option 1: Upcase the first letter, leave all the other letters alone. This is 
consistent with all of the examples shown in the API design guidelines, and 
produces “IPad”, “LaTeX”, “NeXT”, and “NaN”. (In context, that might be 
“supportsIPad”, “LaTeXRenderer”, “isNeXTPlatform”, and “signalingNaN”, 
alongside “ipadIcon”, “latexSource”, “nextLogo”, and “nanValue”.)

Option 2: If any letters are lowercase, upcase the first letter and downcase 
all other letters. This is also consistent with all of the examples shown in 
the API design guidelines, and produces “Ipad”, “Latex”, “Next”, and “Nan”. (In 
context, that’s “supportsIpad”, “LatexRenderer”, “isNextPlatform”, and 
“signalingNan”, alongside “ipadIcon”, “latexSource”, “nextLogo”, and 
“nanValue”.)

I prefer option 1 because I think it’s easier to recognize the original form of 
the word; DaveA notes that under option 2 it’s easier to find the word 
boundaries.

(“NeXT” is an especially tricky case because without case it’s not 
distinguishable from the normal word “next”. This situation is rare but not 
nonexistent. Then again, “Apple” is not distinguishable from the normal word 
“apple” either, and we seem to do fine there.)

Thoughts?
Jordan

P.S. The rules also don’t special-case all-lowercase initialisms, like “mph” 
(for “miles per hour”). Under either option above, we’d get “Mph”. If we want 
some other behavior, 
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Reply via email to