<div dir="ltr">I actually feel exactly the opposite of this—personally I thought `private` was fine the way it was when it meant `fileprivate` and I had no real need for `private` as it exists in Swift 3.<div><br></div><div>`fileprivate` is useful because it lets me organize my code in such a way that I divide large types (for example, those that conform to many delegates/other protocols) into multiple extensions in the same file. Any state or helpers that I want to keep in the main class can be defined as `fileprivate` and still be accessible throughout that file, without leaking them into the rest of my module if they were defined as `internal`.</div><div><br></div><div>On the other hand, `private` would mostly just protect me from myself at a very small level. In all the Swift code that I've written (this is my anecdotal experience, of course, and I know others differ), it's rare that I've found a strong reason to or benefit from locking something down as `private` instead of `fileprivate`.</div><div><br></div><div>Of course, one could argue that `fileprivate` is also protecting me from myself, just a file-based level instead of a scope-based level, but I think it would be more harmful to encourage leaking abstractions out of a file and into a module than it would to leak them out of a scope and into a single file. The affected surface area is much smaller in the latter case.</div><div><br></div><div>One possible compromise that pops into my head would be to let `private` not apply to a scope but to a type and also to only those extensions on that type that are visible in the same file—that may have already been discussed during the review of the original proposal. I don't know what the complexity of it would be.</div><div><br></div><div>Either way, I would be strongly against anything that removes `fileprivate`. I don't find much use for `private` and nobody is forcing me to use it, so I don't. On the other hand, removing `fileprivate` would prevent a design and code organization pattern that I enjoy about Swift.</div><div><br></div><div><br><br><div class="gmail_quote"><div dir="ltr">On Fri, Oct 7, 2016 at 2:06 PM Zach Waldowski via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><u class="gmail_msg"></u>
<div class="gmail_msg"><div style="font-family:Arial" class="gmail_msg">I third this sentiment. fileprivate is a nice idea and very clearly has its uses (which is why the proposal got traction in the first place), but when combined with the other access levels, the language feature as a whole feels arbitrary. In practical use, files that I felt were nicely encapsulated and hiding implementation details are now a scattered mix of access levels, adding cognitive load and making the code look unorganized for having the gall to use extensions to split up functionality.<br class="gmail_msg"></div>
<div style="font-family:Arial" class="gmail_msg"><br class="gmail_msg"></div>
<div id="m_-7854324485336707432sig40804545" class="gmail_msg"><div class="m_-7854324485336707432signature gmail_msg"><span class="m_-7854324485336707432font gmail_msg" style="font-family:arial,sans-serif,sans-serif">Sincerely,</span><span class="m_-7854324485336707432font gmail_msg" style="font-family:arial,sans-serif,sans-serif"></span><br class="gmail_msg"></div>
<div class="m_-7854324485336707432signature gmail_msg"><span class="m_-7854324485336707432font gmail_msg" style="font-family:arial,sans-serif,sans-serif"> Zachary Waldowski</span><span class="m_-7854324485336707432font gmail_msg" style="font-family:arial,sans-serif,sans-serif"></span><br class="gmail_msg"></div>
<div class="m_-7854324485336707432signature gmail_msg"><span class="m_-7854324485336707432font gmail_msg" style="font-family:arial,sans-serif,sans-serif"> </span><a href="mailto:zach@waldowski.me" class="gmail_msg" target="_blank"><span class="m_-7854324485336707432font gmail_msg" style="font-family:arial,sans-serif,sans-serif">zach@waldowski.me</span></a><br class="gmail_msg"></div>
</div></div><div class="gmail_msg">
<div class="gmail_msg"><br class="gmail_msg"></div>
<div class="gmail_msg"><br class="gmail_msg"></div>
<div class="gmail_msg">On Fri, Oct 7, 2016, at 01:55 PM, Russ Bishop via swift-evolution wrote:<br class="gmail_msg"></div>
<blockquote type="cite" class="gmail_msg"><div class="gmail_msg"><br class="gmail_msg"></div>
<div class="gmail_msg"><blockquote type="cite" class="gmail_msg"><div class="gmail_msg">On Oct 7, 2016, at 9:13 AM, David Hart via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a>> wrote:<br class="gmail_msg"></div>
<div style="font-family:Arial" class="gmail_msg"><br class="gmail_msg"></div>
<div class="gmail_msg"><div style="word-wrap:break-word" class="gmail_msg"><div style="font-family:Arial" class="gmail_msg">I started the topic, but I also believe like you that the <b class="gmail_msg">fileprivate</b> vs <b class="gmail_msg">private(file)</b> discussion has already been thoroughly discussed and nothing new has been brought up. That’s not what I want to discuss.<br class="gmail_msg"></div>
<div class="gmail_msg"><br class="gmail_msg"></div>
<div class="gmail_msg">I instead want to share my experience using <b class="gmail_msg">private</b> and <b class="gmail_msg">fileprivate</b> since release. Here are my thoughts:<br class="gmail_msg"></div>
<div class="gmail_msg"><br class="gmail_msg"></div>
<div class="gmail_msg"><ol class="gmail_msg"><li class="gmail_msg">We should start with the premise that the proposal has added a substantial amount of complexity:<br class="gmail_msg"></li><ol class="gmail_msg"><li class="gmail_msg">It has added an extra modifier and access level to learn.<br class="gmail_msg"></li><li class="gmail_msg">It has complicated the access level rules with Inner types as mentioned in the <b class="gmail_msg">Complications with private types</b> section of the proposal.<br class="gmail_msg"></li><li class="gmail_msg">I have seen many people (twitter, work, slack) be confused about the difference between <b class="gmail_msg">private</b> and <b class="gmail_msg">fileprivate</b> at the global level. The answer is none, which shows that both modifiers are not very orthogonal.<br class="gmail_msg"></li><li class="gmail_msg">Since release, I saw people prefer one over the other, as a matter of style. They tend to always use <b class="gmail_msg">fileprivate</b> or always using <b class="gmail_msg">private</b>. In the latter case, functions and properties get clumped in the same class scope instead of be written through multiple extensions.<br class="gmail_msg"></li></ol><li class="gmail_msg">I have the impression that the motivations for the proposal are much less real in practice:<br class="gmail_msg"></li><ol class="gmail_msg"><li class="gmail_msg">The first motivation stated is: <i class="gmail_msg">"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.<br class="gmail_msg"></li><li class="gmail_msg">The second motivation stated is: <i class="gmail_msg">"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.<br class="gmail_msg"></li></ol></ol><div class="gmail_msg"><br class="gmail_msg"></div>
</div>
<div class="gmail_msg">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.<br class="gmail_msg"></div>
<div class="gmail_msg"><br class="gmail_msg"></div>
<div class="gmail_msg">Thoughts?<br class="gmail_msg"></div>
<div class="gmail_msg">David.<br class="gmail_msg"></div>
<div class="gmail_msg"><div class="gmail_msg"><br class="gmail_msg"></div>
</div>
</div>
</div>
</blockquote><div style="font-family:Arial" class="gmail_msg"><br class="gmail_msg"></div>
</div>
<div class="gmail_msg"><br class="gmail_msg"></div>
<div class="gmail_msg">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.<br class="gmail_msg"></div>
<div class="gmail_msg"><br class="gmail_msg"></div>
<div class="gmail_msg"><br class="gmail_msg"></div>
<div class="gmail_msg"><br class="gmail_msg"></div>
<div class="gmail_msg">Russ<br class="gmail_msg"></div>
<div style="font-family:Arial" class="gmail_msg"><br class="gmail_msg"></div>
<div class="gmail_msg"><u class="gmail_msg">_______________________________________________</u><br class="gmail_msg"></div>
<div class="gmail_msg">swift-evolution mailing list<br class="gmail_msg"></div>
<div class="gmail_msg"><a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a><br class="gmail_msg"></div>
<div class="gmail_msg"><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="gmail_msg"></div>
</blockquote><div style="font-family:Arial" class="gmail_msg"><br class="gmail_msg"></div>
</div>
_______________________________________________<br class="gmail_msg">
swift-evolution mailing list<br class="gmail_msg">
<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a><br class="gmail_msg">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" class="gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="gmail_msg">
</blockquote></div></div></div>