[resending to include list] Hm. I’m not sure why these words would be special, though—if we were going to use underscores, shouldn’t we consistently go for “snake_case” or something?
(A leading underscore is also often used to denote something private in a lot of conventions, including the standard library.) Jordan > On May 5, 2016, at 08:38, Basem Emara <[email protected] > <mailto:[email protected]>> wrote: > > Indeed the scenario has always been tricky for conventions. In both option 1 > and 2, it looses the meaning, so I propose option 3 (which still sux too ha): > > Option 3: Surround with underscores to isolate the acronym with mixed casing. > It clearly retains the original meaning since acronys already create > ambigiouty. An added degree of ambiguity could lose it’s meaning complete. > This way with underscores, it is clear what it is referring to. In context, > that might be “supports_iPad”, “_LaTeX_Renderer”, “is_NeXT_Platform”, and > “signaling_NaN”, alongside “_iPad_Icon”, “_LaTeX_Source”, “_NeXT_Logo”, and > “_NaN_Value”.) > >> On May 5, 2016, at 11:26 AM, Jordan Rose via swift-evolution >> <[email protected] <mailto:[email protected]>> wrote: >> >> 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 >> [email protected] <mailto:[email protected]> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> <https://lists.swift.org/mailman/listinfo/swift-evolution> >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
