<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">Terminology-wise, most of these are not <a href="https://en.wiktionary.org/wiki/acronym#Noun" class="">acronyms</a> (or <a href="https://en.wiktionary.org/wiki/initialism#Noun" class="">initialisms</a>), but you’re right that that’s a third option consistent with the existing guidelines.</div><div class=""><br class=""></div><div class="">Jordan</div><br class=""><div><blockquote type="cite" class=""><div class="">On May 5, 2016, at 08:56, Basem Emara <<a href="mailto:contact@basememara.com" class="">contact@basememara.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Yes I digress and agree with you consistency is absolute key. Another thought came to mind:<div class=""><br class=""></div><div class=""><b class="">Option <strike class="">3</strike> 3: Uppercase all acronyms including those with mixed casing. </b>This is both consistent and clear. Isolating acronyms is important because they loose their meaning and bleed into word boundaries, so making even mixed acronyms all uppercase clearly identifies them. In context, that might be “supportsIPAD”, “LATEXRenderer”, “isNEXTPlatform”, and “signalingNAN”, alongside “IPADIcon”, “LATEXSource”, “NEXTLogo”, and “NANValue”.)</div><div class=""><br class=""></div><div class=""><blockquote type="cite" class=""><div class="">On May 5, 2016, at 11:41 AM, Jordan Rose <<a href="mailto:jordan_rose@apple.com" class="">jordan_rose@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">[resending to include list]</div><div class=""><br class=""></div>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?<br class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><br class=""></div><div class="">(A leading underscore is also often used to denote something private in a lot of conventions, including the standard library.)</div><div class=""><br class=""></div><div class="">Jordan</div><div class=""><br class=""></div><br class=""><div class=""><blockquote type="cite" class=""><div class="">On May 5, 2016, at 08:38, Basem Emara <<a href="mailto:contact@basememara.com" class="">contact@basememara.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><span class="">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):</span></div><div class=""><span class=""><br class=""></span></div><b class="">Option 3: Surround with underscores to isolate the acronym with mixed casing. </b>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”.)<div class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On May 5, 2016, at 11:26 AM, Jordan Rose via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Hi, everyone. Today in the <a href="https://swift.org/documentation/api-design-guidelines/" class="">API Design Guidelines</a> we have this section on case:<div class=""><br class=""></div><div class=""></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class=""></div></blockquote><blockquote type="cite" class=""><div class=""><b class="">Follow case conventions</b>. Names of types and protocols are <font face="Menlo" class=""><span style="font-size: 11px;" class="">UpperCamelCase</span></font>. Everything else is <font face="Menlo" class=""><span style="font-size: 11px;" class="">lowerCamelCase</span></font>.<br class=""><br class="">Acronyms and initialisms that commonly appear as all upper case in American English should be uniformly up- or down-cased according to case conventions:<br class=""><br class=""></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class="">var <b class="">utf8</b>Bytes: [<b class="">UTF8</b>.CodeUnit]</div><div class=""><div class="">var isRepresentableAs<b class="">ASCII</b> = true</div></div><div class=""><div class="">var user<b class="">SMTP</b>Server: Secure<b class="">SMTP</b>Server</div></div></blockquote><div class=""><br class="Apple-interchange-newline">Other acronyms should be treated as ordinary words:<br class=""><br class=""></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class="">var <b class="">radar</b>Detector: <b class="">Radar</b>Scanner</div><div class=""><div class="">var enjoys<b class="">Scuba</b>Diving = true</div></div></blockquote></blockquote><br class=""><div class="">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.)</div><div class=""><br class=""></div><div class="">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:</div><div class=""><br class=""></div><div class=""><b class="">Option 1: Upcase the first letter, leave all the other letters alone. </b>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”.)</div><div class=""><br class=""></div><div class=""><b class="">Option 2: If any letters are lowercase, upcase the first letter and downcase all other letters.</b> This is <i class="">also</i> 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”.)</div><div class=""><br class=""></div><div class="">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 <i class="">boundaries</i>.</div><div class=""><br class=""></div><div class="">(“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.)</div><div class=""><br class=""></div><div class="">Thoughts?</div><div class="">Jordan</div><div class=""><br class=""></div><div class="">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, </div></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></blockquote></div><br class=""></div></div></div></blockquote></div><br class=""></div></div><br class=""></div></div></blockquote></div><br class=""></div></div></blockquote></div><br class=""></body></html>