[swift-evolution] SE-0025: Scoped Access Level, next steps

[Haravikk]

> On 26 Mar 2016, at 14:11, Ross O'Brien <narrativium+swift at gmail.com> wrote:
> 
> Haravikk: private (type) would be the subject of another proposal.
> 
> What this proposal is about is the following (all in one file):
> 
> struct Foo {
>     func doThing() {
>         doPrivateThing()
>     }
> 
>     private func doPrivateThing() { }
> }
> 
> extension Foo {
>     func doOtherThing() {
>         doPrivateThing()
>     }
> 
>     private func doPrivateThing() { }
> }
> 
> 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.

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

> 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.
> 
> Chris Lattner's explained the reasoning about conjoined keywords in a few places I think, but the posts from this thread are here:
> 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>
> 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>
> 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>
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.

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160326/debf66dc/attachment.html>