On Mar 24, 2016, at 6:02 AM, John Siracusa via swift-evolution <swift-evolution@swift.org> wrote: > How about we continue this trend, and follow other existing Swift keywords > that merge two lowercase words (associatedtype, typealias, etc), and use: > > public > moduleprivate > fileprivate > private > > Why is it important to highlight word boundaries in so many other conventions > in Swift but not in this one? What would be lost with this alternative? > > public > module_private > file_private > private > > Is it just the extra (chorded, on US keyboards) keystroke? I think the > readability benefits of clear word boundaries far outweigh the keystroke cost > (especially with good editor auto-complete). > > I also think the precedent of nameslikethis is a dangerous one for > readability. It's easy to say this is "just for this limited area of the > language," but witness how associatedtype is already used to support > moduleprivate and friends. Precedents matter, and I think this is not a good > one.
Hi John, Great question. The core team has discussed this (extensively, on multiple occasions, sigh.. :-). The conclusion is to standardize on a simple and consistent schema of: 1. Keywords & declaration modifiers all lower case, conjoined when multi-word. 2. Attributes and values (which includes methods and enum cases) being lower camel case. 3. Types being upper camel case. This approach eliminates the “snake" case we had before, but “camel fans" often raise the question of why we don’t apply lower camel case to keywords. There are a couple of reasons for this: 1. Keywords, as part of the language, are extremely carefully considered and scrutinized by a large community of smart folks on swift-evolution. Taking a word (e.g. “in” or “for”) is something that has to be carefully balanced vs the impact on real world code in various domains. It isn’t done lightly. 2. Lower camel case is already used for values. Keyword/value conflicts are a real thing, particularly when it comes to expressive APIs. We have solved this for keyword arguments to methods, but conflicts on property names are still a very real thing. 3. We have a few conjoined keywords already (typealias, associatedtype, fallthrough). In the discussion about these terms, we decided that these read best when all lowercase, because they are treated as atomic concepts by programmers. It is reasonable to expect a Swift programmer to grok (as they incrementally gain mastery of the language) the builtin language keywords. Syntax highlighting and other IDE features also help here. That said, to be fair, there is more work to be done here in Swift 3, because we still have the legacy dynamicType keyword - it should be renamed to “dynamictype" IMO. 4. Declaration modifiers (like public/private/moduleprivate/etc) don’t have to live by the same rules as keywords necessarily (the grammar of Swift allows us to precisely disambiguate decl-modifiers based on the keyword they hang off of), but Swift programmers think of them as keywords, and so it is most consistent for them to follow the naming scheme of keywords. 5. In contrast, attributes are intentionally “demoted” in prominence for various reasons, and require an @ prefix. We also expect and hope to support user defined attributes at some point. As such, lower-camel-case (when not containing a framework prefix like NS or UI) is the best approach for them. These are all reasons why we go with conjoined keywords instead of lower-camel-case. If you are really asking why we don’t go with *snake* case, the answer is somewhat simpler: Swift is an “opinionated” language and we find snake case to be ugly (YMMV of course). -Chris
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
