<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Mar 24, 2016 at 1:13 AM, Chris Lattner via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><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">On Mar 15, 2016, at 3:39 AM, Thorsten Seitz via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br>
> public<br>
> private-module<br>
> private-file<br>
> private<br>
<br>
This follows the same sort of structure as James’ proposal, without the parens. It has the same advantages, but trades them with hyphenated decl modifiers. We don’t do that, but it is a good direction.<br>
<br>
How about we continue this trend, and follow other existing Swift keywords that merge two lowercase words (associatedtype, typealias, etc), and use:<br>
<br>
public<br>
moduleprivate<br>
fileprivate<br>
private<br></blockquote><div><br></div><div>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><br></div><div>public</div><div>module_private</div><div>file_private</div><div>private</div><div><br></div><div>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><br></div><div>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><br></div><div>-John</div><div><br></div></div></div></div>