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