<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="">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><blockquote type="cite" class=""><div class="">On 7 Oct 2016, at 17:21, Xiaodi Wu 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="">While no topic is formally off the table, to revisit a topic requires fresh insight. `private(file)` was suggested at the time and rejected in favor of `fileprivate`, and we really don't need another rehash of how much each person likes one or the other.<br class=""><div class="gmail_quote"><div dir="ltr" class="">On Fri, Oct 7, 2016 at 09:02 Adriano Ferreira via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class="gmail_msg">+1<br class="gmail_msg"><br class="gmail_msg">I would also rather have:<br class="gmail_msg"><br class="gmail_msg">private(scope)<br class="gmail_msg">private(file)<br class="gmail_msg">private(module)<br class="gmail_msg">etc…</div><div style="word-wrap:break-word" class="gmail_msg"><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">— A</div></div><div style="word-wrap:break-word" class="gmail_msg"><div class="gmail_msg"><br class="gmail_msg"><div class="gmail_msg"><blockquote type="cite" class="gmail_msg"><div class="gmail_msg">On Oct 7, 2016, at 4:24 AM, Haravikk via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a>> wrote:</div><br class="m_8037717576085946209Apple-interchange-newline gmail_msg"><div class="gmail_msg"><div style="word-wrap:break-word" class="gmail_msg"><br class="gmail_msg"><div class="gmail_msg"><blockquote type="cite" class="gmail_msg"><div class="gmail_msg">On 7 Oct 2016, at 07:39, David Hart via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a>> wrote:</div><br class="m_8037717576085946209Apple-interchange-newline gmail_msg"><div class="gmail_msg"><div style="word-wrap:break-word" class="gmail_msg">Hello community,<div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">From all the proposals which has gone into Swift 3, <b class="gmail_msg">[SE-0025] Scoped Access Level</b> is the only one I’m having second thoughts about. Before launching a discussion around it, I’m curious to know if it's worth discussing it or if the “ship has sailed”. As the plan is to allow future versions of Swift to break source-compatibility in certain rare scenarios, perhaps we have a chance to reconsider certain proposals?</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">Regards,</div><div class="gmail_msg">David.</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" class="gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="gmail_msg"></div></blockquote></div><br class="gmail_msg"><div class="gmail_msg">What in particular don't you like about it?</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">Personally I still don't like the use of fileprivate as the keyword, I was very much in favour of a bracketed system like:</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg"><span class="gmail_msg m_8037717576085946209Apple-tab-span" style="white-space:pre-wrap"> </span>private(scope)<span class="gmail_msg m_8037717576085946209Apple-tab-span" style="white-space:pre-wrap"> </span>Current private (I think, it doesn't appear to be equivalent to protected in other languages anyway so I wouldn't call it type).</div><div class="gmail_msg"><span class="gmail_msg m_8037717576085946209Apple-tab-span" style="white-space:pre-wrap"> </span>private(file)<span class="gmail_msg m_8037717576085946209Apple-tab-span" style="white-space:pre-wrap"> </span>Current fileprivate</div><div class="gmail_msg"><span class="gmail_msg m_8037717576085946209Apple-tab-span" style="white-space:pre-wrap"> </span>private(module)<span class="gmail_msg m_8037717576085946209Apple-tab-span" style="white-space:pre-wrap"> </span>Current internal/default when omitted</div><div class="gmail_msg"><span class="gmail_msg m_8037717576085946209Apple-tab-span" style="white-space:pre-wrap"> </span>public<span class="gmail_msg m_8037717576085946209Apple-tab-span" style="white-space:pre-wrap"> </span>Current public</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">I favour this because it groups all restrictive access levels under private (since they're all some form of private) with an optional modifier that's explicit about what it's for. Also, it would have scope to move things like final into a modifier too, so you might declare a method as public(final), or public(open) if that's implemented later and so-on. Just seems like a generally more flexible setup that also reduces the number of keywords required.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">Some may feel it's noisy, but personally I don't see it as a problem as it always comes before the func/var/let keyword, generics and function name, so it's not like it's near anything where the (minor) noise reduces readability.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">But yeah, having used the new fileprivate for a little while I just don't like it; it may partly come down to the fact that I use fileprivate a lot more than I use regular private. If we were to adopt the above scheme I would recommend that private(file) be the default for use of the plain private keyword, unless we gain the ability to specify private(type) (i.e- protected in most other languages), as private(scope) seems like it's the less common, at least in my experience.</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" class="gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="gmail_msg"></div></blockquote></div><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>
_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></div></div></body></html>