<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=""><br class=""></div><div><blockquote type="cite" class=""><div class="">On Oct 7, 2016, at 9:13 AM, David Hart via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">I started the topic, but I also believe like you that the <b class="">fileprivate</b> vs <b class="">private(file)</b> discussion has already been thoroughly discussed and nothing new has been brought up. That’s not what I want to discuss.<div class=""><br class=""></div><div class="">I instead want to share my experience using <b class="">private</b> and <b class="">fileprivate</b> since release. Here are my thoughts:</div><div class=""><br class=""></div><div class=""><ol class="MailOutline"><li class="">We should start with the premise that the proposal has added a substantial amount of complexity:</li><ol class=""><li class="">It has added an extra modifier and access level to learn.</li><li class="">It has complicated the access level rules with Inner types as mentioned in the <b class="">Complications with private types</b> section of the proposal.</li><li class="">I have seen many people (twitter, work, slack) be confused about the difference between <b class="">private</b> and <b class="">fileprivate</b> at the global level. The answer is none, which shows that both modifiers are not very orthogonal.</li><li class="">Since release, I saw people prefer one over the other, as a matter of style. They tend to always use <b class="">fileprivate</b> or always using <b class="">private</b>. In the latter case, functions and properties get clumped in the same class scope instead of be written through multiple extensions.</li></ol><li class="">I have the impression that the motivations for the proposal are much less real in practice:</li><ol class=""><li class="">The first motivation stated is: <i class="">"It is not clear whether the implementation details are meant to be completely hidden or can be shared with some related code without the danger of misusing the APIs marked as private.”</i> I’ve found that to be fairly rare in practice because the implementation details only used to leak inside the same file, which greatly reduces the dangers.</li><li class="">The second motivation stated is: <i class="">"It forces a one class per file structure, which is very limiting." </i>First of all, this is partly false. I think it forces putting classes which share implementation details in the same file, which I don’t think is necessarily a bad thing.</li></ol></ol><div class=""><br class=""></div></div><div class="">To summarise, it seems that the confusion the proposal brought over semantics and style are not worth the limited benefits that it brought. I’d be tempted to backtrack the proposal and re-introduce private as a file scoped access-level and deprecate fileprivate.</div><div class=""><br class=""></div><div class="">Thoughts?</div><div class="">David.</div><div class=""><div class=""><br class=""></div></div></div></div></blockquote><br class=""></div><div><br class=""></div><div>I agree. The minor benefit that fileprivate brings is not worth the cognitive overhead it introduces. We should just admit it was a mistake and back it out. We can avoid source-breaking changes by making fileprivate a synonym for private and provide fixits/warnings for a release to give people a chance to move off it.</div><div><br class=""></div><div><br class=""></div><div><br class=""></div><div>Russ</div><br class=""></body></html>