<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="">On Mar 24, 2016, at 6:02 AM, John Siracusa via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><div><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">How about we continue this trend, and follow other existing Swift keywords that merge two lowercase words (associatedtype, typealias, etc), and use:<br class="">
<br class="">
public<br class="">
moduleprivate<br class="">
fileprivate<br class="">
private<br class=""></blockquote><div class=""><br class=""></div><div class="">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?</div><div class=""><br class=""></div><div class="">public</div><div class="">module_private</div><div class="">file_private</div><div class="">private</div><div class=""><br class=""></div><div class="">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).</div><div class=""><br class=""></div><div class="">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.</div></div></div></div></div></blockquote><br class=""></div><div>Hi John,</div><div><br class=""></div><div>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:</div><div><br class=""></div><div>1. Keywords & declaration modifiers all lower case, conjoined when multi-word.</div><div>2. Attributes and values (which includes methods and enum cases) being lower camel case.</div><div>3. Types being upper camel case.</div><br class=""><div class="">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:</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class=""><div class="">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.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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).</div><div class=""><br class=""></div><div class="">-Chris</div><div class=""><br class=""></div></div><div class=""><br class=""></div></body></html>