<html><head></head><body><div style="color:#000; background-color:#fff; font-family:HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif;font-size:16px"><div id="yui_3_16_0_ym18_1_1458823736226_3799">In real life only public and private make sense. So it may be just private and everything else is public by default. Public may stay for compatibility :) </div><div id="yui_3_16_0_ym18_1_1458823736226_3799">And saying that I think there is no need to change anything as the current model is good enough.</div><div id="yui_3_16_0_ym18_1_1458823736226_3799"><br></div><div id="yui_3_16_0_ym18_1_1458823736226_3799">What ever you do - don,t break existing code. Swift is not beta anymore...</div><div id="yui_3_16_0_ym18_1_1458823736226_3799">No one can invest in big projects if the syntax is unstable!</div><div id="yui_3_16_0_ym18_1_1458823736226_3799"><br></div> <div class="qtdSeparateBR"><br><br></div><div class="yahoo_quoted" style="display: block;"> <div style="font-family: HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif; font-size: 16px;"> <div style="font-family: HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif; font-size: 16px;"> <div dir="ltr"><font size="2" face="Arial"> On Thursday, March 24, 2016 2:17 PM, Goffredo Marocchi via swift-evolution <swift-evolution@swift.org> wrote:<br></font></div> <br><br> <div class="y_msg_container"><div id="yiv0270788432"><div><div>I think that s<b style="margin:0px;padding:0px;border:0px;line-height:inherit;vertical-align:baseline;background-image:none;">upercalifragilisticexpialidocious</b> may benefit from lowerCamelCasing ;).<br clear="none"><br clear="none">[[iOS messageWithContent:webContent] broadcast]</div><div><div class="yiv0270788432yqt5020627443" id="yiv0270788432yqtfd40763"><br clear="none">On 24 Mar 2016, at 11:02, Dany St-Amant via swift-evolution <<a rel="nofollow" shape="rect" ymailto="mailto:swift-evolution@swift.org" target="_blank" href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br clear="none"><br clear="none"></div></div><div class="yiv0270788432yqt5020627443" id="yiv0270788432yqtfd63719"><blockquote type="cite"><div><span></span><br clear="none"><blockquote type="cite"><span>Le 24 mars 2016 à 01:13, Chris Lattner via swift-evolution <<a rel="nofollow" shape="rect" ymailto="mailto:swift-evolution@swift.org" target="_blank" href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> a écrit :</span><br clear="none"></blockquote><blockquote type="cite"><span></span><br clear="none"></blockquote><blockquote type="cite"><span><responding to several posts in this thread at once></span><br clear="none"></blockquote><blockquote type="cite"><span></span><br clear="none"></blockquote><blockquote type="cite"><span>[..snip..]</span><br clear="none"></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 clear="none"></blockquote><blockquote type="cite"><span></span><br clear="none"></blockquote><blockquote type="cite"><span> public</span><br clear="none"></blockquote><blockquote type="cite"><span> moduleprivate</span><br clear="none"></blockquote><blockquote type="cite"><span> fileprivate</span><br clear="none"></blockquote><blockquote type="cite"><span> private</span><br clear="none"></blockquote><blockquote type="cite"><span></span><br clear="none"></blockquote><blockquote type="cite"><span>The advantages, as I see them are:</span><br clear="none"></blockquote><blockquote type="cite"><span>1) We keep public and private meaning the “right” and “obvious” things.</span><br clear="none"></blockquote><blockquote type="cite"><span>2) The declmodifiers “read” correctly.</span><br clear="none"></blockquote><blockquote type="cite"><span>3) The unusual ones (moduleprivate and fileprivate) don’t use the awkward parenthesized keyword approach.</span><br clear="none"></blockquote><blockquote type="cite"><span>4) The unusual ones would be “googable”.</span><br clear="none"></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). Putting an identifier in the parens is much more natural than putting keywords in parens.</span><br clear="none"></blockquote><blockquote type="cite"><span></span><br clear="none"></blockquote><blockquote type="cite"><span>What do you all think?</span><br clear="none"></blockquote><span></span><br clear="none"><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 clear="none"><span>Obviously, I am on the "all keywords should be all lowercases" team.</span><br clear="none"><span></span><br clear="none"><span>Dany</span><br clear="none"><span>_______________________________________________</span><br clear="none"><span>swift-evolution mailing list</span><br clear="none"><span><a rel="nofollow" shape="rect" ymailto="mailto:swift-evolution@swift.org" target="_blank" href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a></span><br clear="none"><span><a rel="nofollow" shape="rect" target="_blank" href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br clear="none"></div></blockquote></div></div></div><br><div class="yqt5020627443" id="yqtfd71120">_______________________________________________<br clear="none">swift-evolution mailing list<br clear="none"><a shape="rect" ymailto="mailto:swift-evolution@swift.org" href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br clear="none"><a shape="rect" href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br clear="none"></div><br><br></div> </div> </div> </div></div></body></html>