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

[BJ Homer]

What is your evaluation of the proposal?
I agree with the proposal. While I acknowledge that a lexically-scoped access modifier can be useful, giving it the name “private” in Swift is unfortunate. Much of the existing Swift training material suggests a common pattern of adding protocol conformances via extensions. For example, this kind of code is very common:

class ToyViewController: UIViewController {
  private var toysToDisplay: [Toy]
}

extension ToyViewController: UICollectionViewDataSource {
  // Implement the data source protocol here
}

However, this pattern is broken; toysToDisplay cannot be labeled private because then it cannot be accessed within the extension. It needs to be fileprivate instead. But this adds a barrier to learning; while private is a common programming term, fileprivate is not. Most users will try private first. I believe Swift should intentionally be biased toward ease of use, and the use of private to signify scope-level access goes against that principle.

There was an argument earlier in the thread that extensions are intended for augmenting a type from the outside. In my experience, it is equally common to have a type and extensions on that type in the same file. This has been demonstrated in WWDC sessions, in training documents, and is common practice among many of the Swift developers I have worked with.

In Swift 3, there is tension between adding protocol conformances in extensions and having private as the soft default for limiting access. I agree that a lexically-scoped access modifier can be useful, but I think it should be spelled scoped. “private” should revert to its Swift 2 meaning, which is more compatible with the extension- and protocol-oriented nature of Swift. It would be nice if we could make both changes at once, but if that is not possible, it would be better to make the potentially source-breaking change in the Swift 4 timeline, as the bar for source-breaking changes will only increase with each release. "Scoped" access can be added back after Swift 4, if it cannot be part of this release.


Is the problem being addressed significant enough to warrant a change to Swift?
Yes. The requirement to use fileprivate when adding extensions within the same file makes Swift more difficult to learn.
Does this proposal fit well with the feel and direction of Swift?
Yes. Swift is intended to be a language that is both easy to learn and easy to use. The common use of private makes the language more difficult to learn. “scoped” access should be a more advanced feature.
If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
Swift is intentionally different here, and I think it’s correct for Swift to be different.
How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
I followed the SE-0025 conversation, this conversation, and have used both Swift 2 and Swift 3 extensively. Even though I know that I’m usually going to need fileprivate, it’s such an awkward term that I usually end up writing private anyway, and then regretting it. Ideally, we would continue supporting both scoped and file-level access control, by renaming both of them. But because of the increasing bar for source compatibility, I think it’s better to make this change now, and reintroduce scoped access as soon as possible.

-BJ



> On Mar 20, 2017, at 5:54 PM, Douglas Gregor via swift-evolution <swift-evolution at swift.org> wrote:
> 
> Hello Swift community,
> 
> The review of SE-0159 "Fix Private Access Levels" begins now and runs through March 27, 2017. The proposal is available here:
> 
> https://github.com/apple/swift-evolution/blob/master/proposals/0159-fix-private-access-levels.md <https://github.com/apple/swift-evolution/blob/master/proposals/0159-fix-private-access-levels.md>
> Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at
> 
> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
> or, if you would like to keep your feedback private, directly to the review manager. When replying, please try to keep the proposal link at the top of the message:
> 
> Proposal link:
> 
> https://github.com/apple/swift-evolution/blob/master/proposals/0159-fix-private-access-levels.md <https://github.com/apple/swift-evolution/blob/master/proposals/0159-fix-private-access-levels.md>
> Reply text
> Other replies
>  <https://github.com/apple/swift-evolution/blob/master/process.md#what-goes-into-a-review-1>What goes into a review?
> 
> The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift. When writing your review, here are some questions you might want to answer in your review:
> 
> What is your evaluation of the proposal?
> Is the problem being addressed significant enough to warrant a change to Swift?
> Does this proposal fit well with the feel and direction of Swift?
> If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
> How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
> More information about the Swift evolution process is available at
> 
> https://github.com/apple/swift-evolution/blob/master/process.md <https://github.com/apple/swift-evolution/blob/master/process.md>
> Thank you,
> 
> -Doug
> 
> Review Manager
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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