Sent from my iPad
> On May 5, 2016, at 10:41 AM, Jordan Rose via swift-evolution > <swift-evolution@swift.org> wrote: > > [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? > +1. Mixing the two is just ugly IMO. I prefer snake case to camel case in general but it seems way too late to make that change in Swift now even if we wanted to and it would complicate import of Objective-C. > (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 <cont...@basememara.com> 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 >>> <swift-evolution@swift.org> wrote: >>> >>> Hi, everyone. Today in the 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 > > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
