<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><br class=""></div><div><blockquote type="cite" class=""><div class="">On 26 Mar 2016, at 14:11, Ross O'Brien <<a href="mailto:narrativium+swift@gmail.com" class="">narrativium+swift@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">Haravikk: private (type) would be the subject of another proposal.<div class=""><br class=""></div><div class="">What this proposal is about is the following (all in one file):<div class=""><br class=""></div><div class="">struct Foo {</div><div class=""> func doThing() {</div><div class=""> doPrivateThing()</div><div class=""> }</div><div class=""><br class=""></div><div class=""> private func doPrivateThing() { }</div><div class="">}</div><div class=""><br class=""></div><div class="">extension Foo {</div><div class=""> func doOtherThing() {</div><div class=""> doPrivateThing()</div><div class=""> }</div><div class=""><br class=""></div><div class=""> private func doPrivateThing() { }</div><div class="">}</div><div class=""><br class=""></div><div class="">There would be two functions called doPrivateThing(). The first is private to the struct declaration; the second to the extension. There's no conflict between them.</div></div></div></div></blockquote><div><br class=""></div><div>I wasn’t actually trying to propose a new form of visibility, but the keyword discussion keeps coming up on various types of visibility so I guess I’m just getting confused with my terminology in these cases. My point was to re-raise the private(foo) style rather than cover some other type of visibility. It also doesn’t help that everyone has different names on what everything should named, but then that’s partly the point I was trying to make =D</div><br class=""><blockquote type="cite" class=""><div dir="ltr" class=""><div class=""><div class="">The reason we continue to have confusion about this (I'm guilty of this too) is because "private" has a standard meaning in many languages and a non-standard meaning in Swift.</div><div class=""><br class=""></div></div><div class="">Chris Lattner's explained the reasoning about conjoined keywords in a few places I think, but the posts from this thread are here:</div><div class=""><a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160321/013261.html" class="">https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160321/013261.html</a><br class=""></div><div class=""><a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160321/013439.html" class="">https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160321/013439.html</a><br class=""></div><div class=""><a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160321/013463.html" class="">https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160321/013463.html</a></div></div></blockquote><br class=""></div><div>Thanks for linking these, but I really don’t like any of the proposed conjoined keywords any more than I like the suggested single-word alternatives, which is why I really feel that the parenthesised restriction is a much better style, as we can argue forever on what the best new visibility keywords and nothing will be good enough IMO. The parenthesised style however means that we not only avoid keyword bloat, we would actually remove one, plus we get the same benefit to clarity of having two-word visibility without the nastiness of the various conjoined options I’ve seen so far.</div><div><br class=""></div><div>Other than it being “weird and awkward” I don’t see any real reasons why we can’t just the private(foo) style; it’s not really more awkward than a conjoined keyword, and I think that the logical grouping is worth it being a bit different. In fact, in the first linked post Chris points out that well chosen public/private defaults should be all that most people need, so you only need the parenthesis for the more unusual cases which I think makes it ideal.</div></body></html>