<div dir="ltr">Haravikk: private (type) would be the subject of another proposal.<div><br></div><div>What this proposal is about is the following (all in one file):<div><br></div><div>struct Foo {</div><div>    func doThing() {</div><div>        doPrivateThing()</div><div>    }</div><div><br></div><div>    private func doPrivateThing() { }</div><div>}</div><div><br></div><div>extension Foo {</div><div>    func doOtherThing() {</div><div>        doPrivateThing()</div><div>    }</div><div><br></div><div>    private func doPrivateThing() { }</div><div>}</div><div><br></div><div>There would be two functions called doPrivateThing(). The first is private to the struct declaration; the second to the extension. There&#39;s no conflict between them.</div><div><br></div><div>What you suggest would be a proposal of its own - it would have to be, because types can be extended outside of their original modules, which would beg the question of whether a property could actually be a &#39;public (type)&#39; rather than a &#39;private (type)&#39;.</div><div><br></div><div>The reason we continue to have confusion about this (I&#39;m guilty of this too) is because &quot;private&quot; has a standard meaning in many languages and a non-standard meaning in Swift.</div><div><br></div></div><div>Chris Lattner&#39;s explained the reasoning about conjoined keywords in a few places I think, but the posts from this thread are here:</div><div><a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160321/013261.html">https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160321/013261.html</a><br></div><div><a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160321/013439.html">https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160321/013439.html</a><br></div><div><a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160321/013463.html">https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160321/013463.html</a><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Mar 26, 2016 at 9:13 AM, Haravikk <span dir="ltr">&lt;<a href="mailto:swift-evolution@haravikk.me" target="_blank">swift-evolution@haravikk.me</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div>I can’t find a reply that seemed to cover this so I’d like to ask again, but why just you a parameter on private for all hidden visibility types? i.e-</div><div><br></div><div><span style="white-space:pre-wrap">        </span>public<span style="white-space:pre-wrap">                        </span>(current meaning of public)</div><div><span style="white-space:pre-wrap">        </span>private (module)<span style="white-space:pre-wrap">        </span>(current meaning of internal)</div><div><span style="white-space:pre-wrap">        </span>private (type)<span style="white-space:pre-wrap">                </span>(new scoped visibility, could be named scoped instead but I prefer type personally)</div><div><span style="white-space:pre-wrap">        </span>private (file)<span style="white-space:pre-wrap">                </span>(current meaning of private)</div><div><br></div><div>This eliminates the need for an additional keyword, and actually trims internal as well, plus all visibility is then either public (externally accessible) or private (internally accessible with some degree of restriction). When used without a parameter private on its own would now default to private (type).</div><div><br></div><div>The ability to place a visibility restriction only upon a getter/setter would be handled as a parameter value, for example:</div><div><br></div><div><span style="white-space:pre-wrap">        </span>private (file: set)<span style="white-space:pre-wrap">                        </span>(value can only be set within this file)</div><div><span style="white-space:pre-wrap">        </span>private (type: get, file: set)<span style="white-space:pre-wrap">        </span>(value is accessible within type, sub-types and extensions, but can only be set within this file)</div><div><br></div><div>I think it’s a very neat way to do things, and I think that for most cases private (type), the new default for private, is sufficient for a lot of use-cases. More importantly it eliminates the need for new keywords, actually trims one (we only need two for visibility not four) and also eliminates the need to find good single-word keywords that make sense on their own, since all limited types are explicitly grouped as private which should make it absolutely clear.</div><div><div class="h5"><br><div><blockquote type="cite"><div>On 26 Mar 2016, at 07:14, Cheyo Ximenez via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt; wrote:</div><br><div><div dir="auto"><div></div><div>I agree with Ross. Swift already redefined the common access modifiers meanings. </div><div>Why not use the word &#39;protected&#39; to mean &#39;local&#39;?</div><div><br></div><div>public</div><div>internal</div><div>private</div><div>protected // Java got it wrong. :) This is &quot;protected&quot; against extensions.  </div><div><br>On Mar 25, 2016, at 6:57 PM, 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><br></div><blockquote type="cite"><div><div dir="ltr">The specific meaning of &#39;public&#39; and &#39;private&#39; in programming languages refers to type-based symbol visibility. I&#39;m thinking of C++, C#, Java and Objective C; their &#39;public&#39; is Swift&#39;s &#39;internal&#39;. They have no equivalent to Swift&#39;s &#39;public&#39;. Swift has no equivalent to their &#39;private&#39;.<div><br></div><div>Possibly my familiarity with other languages isn&#39;t broad enough, but this is why I haven&#39;t understood the idea that Swift&#39;s use of &#39;private&#39; is &quot;right&quot; or &quot;obvious&quot;. You learn Swift&#39;s meanings of these terms by coding in Swift, you don&#39;t learn these meanings anywhere else first.</div><div><br></div><div>To use a hopefully recognised example: an American who wants &#39;chips&#39; wants what a Brit calls crisps; a Brit who wants chips wants what an American calls french fries. Which meaning of &#39;chips&#39; is more intuitive? Answer: the one you grew up with.<br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Mar 26, 2016 at 1:10 AM, Brent Royal-Gordon 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>&gt; all of these names (public, internal, private, local) have specific meaning in the context of computer languages.<br>
<br>
</span>Yes, `local` has a meaning, but that meaning is generally *not* that it&#39;s an access level. It usually has something to do with declaring variables inside a function.<br>
<br>
For instance, Perl uses it to back up and restore a global variable. ML uses it to create a scope (roughly). Lua and Julia use it to declare lexical variables which are visible in enclosed scopes, which SE-0025&#39;s new access level is specifically *not* supposed to allow.<br>
<br>
I don&#39;t know of any language where `local` is used as an access level. If you&#39;re aware of an analogous use in another language, I&#39;d be interested to see it. But the examples I&#39;ve found if anything *undermine* the suggestion that `local` would be a good keyword choice.<br>
<div><div><br>
--<br>
Brent Royal-Gordon<br>
Architechies<br>
<br>
_______________________________________________<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>
</div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>swift-evolution mailing list</span><br><span><a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></div></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" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br></div></blockquote></div><br></div></div></div></blockquote></div><br></div>