[swift-evolution] [Review] SE-0159: Fix Private Access Levels

[Drew Crawford]

On March 24, 2017 at 7:53:09 PM, Jonathan Hull (jhull at gbis.com) wrote:

It isn’t the fact that there are multiple models, but they way those models interact with each other in the brain.  You can actually have lots of different models without causing confusion, as long as the models fit well together.  It also isn’t the number of access levels that is a problem.  For example, you can have a ton of shirt sizes (XS, S, M, L, XL, XXL, 3XL) and it doesn’t cause more confusion as you add more sizes because they don’t conflict with one another.

A big part of the issue with our current access scheme is how similar the concepts are without being the same.  That is then made worse by the fact that they have been given similar names.
It is unclear what distinction you intend to draw here.  For example, value types and reference types are similar without being the same.  The names of both concepts also contain the substring "type".  So the difference you draw between that situation and the private/fileprivate situation is not immediately clear.

Note also that your list above is a list of typical stumbling blocks for new programmers in most languages. Swift has actually done a remarkable job with most of these through careful design of the way that they are framed / exposed to the programmer.  In general, these things are well separated from each other. 
I do not think Swift has done even a *good* job framing these concepts.  For example

protocol Foo {

    func foo() { }

}

extension Foo {

    func bar() {}

}

One of these is statically dispatched and the other one is dynamically dispatched.  I would guess the vast majority of Swift developers are not aware there's a difference at all, let alone can explain why one is slower in a benchmark.

Swift is good at giving programmers flexibility in their tools.  Here we have two superficially similar tools with slightly different features and performance characteristics, and for most problems it does not even matter which one you choose.  IMO shipping a full toolbox with plenty of overlap is one of the core values of Swift.

I would suggest that the practicable reason we are talking about removing private/fileprivate instead of protocol/extension or reference/value is that while `extension` etc. makes your code more powerful, `private` makes it less powerful.  It is not obvious to everyone why less power is desirable and so here we are.

Do you feel that allowing both scoped private & file-based private is actually important enough to warrant the significant design work it would take to bring it up to par with these other features? 
It is not clear to me what design work is actually outstanding.  I would love to see submodules, but that seems only indirectly related to visibility keywords, and I'm not aware of what you seem to believe we need.

I do use scoped access extensively, and I've left some examples of that upthread.

It is not impossible, but it really doesn’t feel worth the effort to me (say compared to using that time/energy/thought to check off features from the generics manifesto).
Rather, as Carl Brown argued, it would take a lot of time/energy to migrate even the official projects off of private/fileprivate.  Keeping what we have is free, change is what is expensive, and this proposal is change.

 In general, Swift is an opinionated language
Not clear what you mean here either.  Swift is clearly less opinionated than ObjC for example.  I am having trouble connecting this claim to a practical application.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170324/d8bec458/attachment.html>