<div style="white-space:pre-wrap">The last sentence was meant to be:<br>Private and public have well defined meaning, we should keep the same semantics.<br><br>Still, this is an edge case. Maybe we can separate it into another proposal.</div><br><div class="gmail_quote"><div dir="ltr">On Thu, Mar 24, 2016 at 11:42 AM Ilya Belenkiy via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">This is why I&#39;d like private to mean exactly that (no nested class should get access). Then the meaning is clear: it&#39;s as private as it can be :-)<br><br>Private and public have well defined meaning. We <br><div class="gmail_quote"><div dir="ltr">On Thu, Mar 24, 2016 at 11:33 AM Ross O&#39;Brien via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I agree that &#39;private&#39; still feels too subjective on its own. It&#39;s intuitively &#39;not public&#39;; it&#39;s not intuitively the access term for &#39;declaration only&#39;.<div><br></div><div>I&#39;m not opposed to fileprivate and moduleprivate, if we like those terms. I&#39;d just prefer a corresponding scopeprivate or declarationprivate.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Mar 24, 2016 at 3:21 PM, Brandon Knope via swift-evolution <span dir="ltr">&lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span><br>
&gt; How about we continue this trend, and follow other existing Swift keywords that merge two lowercase words (associatedtype, typealias, etc), and use:<br>
&gt;<br>
&gt;    public<br>
&gt;    moduleprivate<br>
&gt;    fileprivate<br>
&gt;    private<br>
&gt;<br>
&gt; The advantages, as I see them are:<br>
&gt; 1) We keep public and private meaning the “right” and “obvious” things.<br>
&gt; 2) The declmodifiers “read” correctly.<br>
&gt; 3) The unusual ones (moduleprivate and fileprivate) don’t use the awkward parenthesized keyword approach.<br>
&gt; 4) The unusual ones would be “googable”.<br>
&gt; 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.<br>
&gt;<br>
&gt; What do you all think?<br>
&gt;<br>
&gt; -Chris<br>
&gt;<br>
&gt;<br>
&gt; _______________________________________________<br>
&gt; swift-evolution mailing list<br>
&gt; <a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
&gt; <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
<br>
</span>I&#39;m not sure my wording will be perfect here, but I will try: I still believe that private is implied in &quot;module&quot; and &quot;file&quot; and the problem is in the name of the plain &quot;private&quot; keyword.<br>
<br>
You may say private is obvious, but when you have moduleprivate and fileprivate, the natural question I ask is &quot;What remaining kind of private is there?&quot; so private&#39;s obviousness is muddied for me when next to moduleprivate and fileprivate.<br>
<br>
I will say I would prefer these keywords to the proposed parameter keywords. I just think:<br>
<br>
file -&gt; implies file only<br>
module -&gt; implies module only<br>
<br>
where adding private to them only adds noise (I.e. fileprivate and moduleprivate)<br>
<br>
Brandon<br>
<div><div>_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</div></div></blockquote></div><br></div>
_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</blockquote></div>
_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</blockquote></div>