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
> <[email protected]> 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
> [email protected]
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
