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


(Karim Nassar) #1

What is your evaluation of the proposal?

A very reluctant -1. “Reluctant" because I suspect that we won’t get another chance to revisit this, and I *do* think it’s broken.

I’m in the camp that believes the result we got out of SE-25 was not helpful to the evolution of Swift, and I would like to see us reverse the decision. I strongly believe that -25 was a mistake, and took access controls in the wrong direction.

However, I’m not blind to the fact that while *I* don’t have much use for `private` in its Swift3 meaning, there are others who are making good use of it. I have no desire to make the language less expressive for them.

I *would* be strongly supportive of a proposal to rename `private` -> `scoped` and `fileprivate` -> `private`. This would solve many of the confusion & complications resulting from -25 without making the language less expressive for those currently depending on `private`. Alas, that is not the proposal being evaluated.

Is the problem being addressed significant enough to warrant a change to Swift?

While I believe that there is a significant problem that needs to be addressed with regards to access controls in Swift, I don’t believe this proposal sufficiently addresses it.

Adding more expressiveness at the smallest end of the visibility spectrum (SE-25) has simply aggravated the “Very Large File” syndrome that continues to plague my Swift projects. IMHO, what we really need is more expressiveness in the *middle* of the spectrum (i.e.: between the Module `internal` and the file `file/private` expression so that we can hide details of tightly coupled implementations within a larger module without glomming all those implementations into a single file.

This proposal doesn’t actually solve the problem, it simply pretties-up the spelling of `fileprivate` and removes a feature (scoped private) that some members of the community seem to depend on.

Does this proposal fit well with the feel and direction of Swift?

Yes. I believe that the spelling `fileprivate` is clunky and inelegant and creates cognitive dissonance by coexisting with `private`, and that private has a non-intuitive meaning to anyone not being taught Swift as their first PL.

If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

Not really applicable.

How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

Have followed the discussion since SE-25 was passed. Have been using Swift since its announcement, studied the proposal and considered its implications for some time.

—Karim