<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>I think that s<b style="margin: 0px; padding: 0px; border: 0px; line-height: inherit; vertical-align: baseline; background-image: none; -webkit-touch-callout: none !important; background-color: rgba(255, 255, 255, 0);">upercalifragilisticexpialidocious</b>&nbsp;may benefit from lowerCamelCasing ;).<br><br>[[iOS messageWithContent:webContent] broadcast]</div><div><br>On 24 Mar 2016, at 11:02, Dany St-Amant via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>&gt; wrote:<br><br></div><blockquote type="cite"><div><span></span><br><blockquote type="cite"><span>Le 24 mars 2016 à 01:13, Chris Lattner via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>&gt; a écrit :</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>&lt;responding to several posts in this thread at once&gt;</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>[..snip..]</span><br></blockquote><blockquote type="cite"><span>How about we continue this trend, and follow other existing Swift keywords that merge two lowercase words (associatedtype, typealias, etc), and use:</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span> &nbsp; &nbsp;public</span><br></blockquote><blockquote type="cite"><span> &nbsp; &nbsp;moduleprivate</span><br></blockquote><blockquote type="cite"><span> &nbsp; &nbsp;fileprivate</span><br></blockquote><blockquote type="cite"><span> &nbsp; &nbsp;private</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>The advantages, as I see them are:</span><br></blockquote><blockquote type="cite"><span>1) We keep public and private meaning the “right” and “obvious” things.</span><br></blockquote><blockquote type="cite"><span>2) The declmodifiers “read” correctly.</span><br></blockquote><blockquote type="cite"><span>3) The unusual ones (moduleprivate and fileprivate) don’t use the awkward parenthesized keyword approach.</span><br></blockquote><blockquote type="cite"><span>4) The unusual ones would be “googable”.</span><br></blockquote><blockquote type="cite"><span>5) Support for named submodules could be “dropped in” by putting the submodule name/path in parens: private(foo.bar.baz) or moduleprivate(foo.bar). &nbsp;Putting an identifier in the parens is much more natural than putting keywords in parens.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>What do you all think?</span><br></blockquote><span></span><br><span>The think I fear with moduleprivate and fileprivate, is that someone will one day suggest to lowerCamelCase them. The parenthesized version was de-facto preventing my fear from ever being reality.</span><br><span>Obviously, I am on the "all keywords should be all lowercases" team.</span><br><span></span><br><span>Dany</span><br><span>_______________________________________________</span><br><span>swift-evolution mailing list</span><br><span><a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></div></blockquote></body></html>