<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><pre style="white-space: pre-wrap; background-color: rgb(255, 255, 255);" class=""></pre></div><blockquote type="cite" class=""><div class=""><pre style="white-space: pre-wrap; background-color: rgb(255, 255, 255);" class="">What is your evaluation of the proposal?
</pre></div></blockquote>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.<div class=""><br class=""></div><div class="">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. </div><div class=""><br class=""></div><div class="">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. </div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class=""><blockquote type="cite" class=""><div class=""><pre style="white-space: pre-wrap; background-color: rgb(255, 255, 255);" class="">Is the problem being addressed significant enough to warrant a change to Swift?
</pre></div></blockquote><div class="">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.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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. </div><div class=""><br class=""></div><blockquote type="cite" class=""><div class=""><pre style="white-space: pre-wrap; background-color: rgb(255, 255, 255);" class="">Does this proposal fit well with the feel and direction of Swift?
</pre></div></blockquote><div class="">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.</div><div class=""><br class=""></div><blockquote type="cite" class=""><div class=""><pre style="white-space: pre-wrap; background-color: rgb(255, 255, 255);" class="">If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
</pre></div></blockquote><div class="">Not really applicable.</div><br class=""><blockquote type="cite" class=""><div class=""><pre style="white-space: pre-wrap; background-color: rgb(255, 255, 255);" class="">How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
</pre></div></blockquote><div class="">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.</div><div class=""><br class=""></div></div><div class="">—Karim</div></body></html>