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