<div><br><div class="gmail_quote"><div dir="auto">On Mon, Oct 9, 2017 at 13:51 C. Keith Ray 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"><div dir="auto"><div><a href="https://developer.apple.com/library/content/documentation/Swift/Conceptual/Swift_Programming_Language/AccessControl.html" target="_blank">https://developer.apple.com/library/content/documentation/Swift/Conceptual/Swift_Programming_Language/AccessControl.html</a></div><div><br></div><div>Says...</div><div><br></div><div><p class="m_7654275773649816155para" style="border:0px;margin:0px 0px 15px;outline:0px;padding:0px;vertical-align:baseline;line-height:24.360000610351563px"><span style="background-color:rgba(255,255,255,0)">"Alternatively, you can mark an extension with an explicit access-level modifier (for example, <code class="m_7654275773649816155code-voice" style="border:0px;margin:0px;outline:0px;padding:0px;vertical-align:baseline;word-break:break-all;word-wrap:break-word">private extension</code>) to set a new default access level for all members defined within the extension. This new default can still be overridden within the extension for individual type members."</span></p><div>And...</div><div><br></div><div><ul class="m_7654275773649816155list-bullet" style="border:0px;margin:0px 0px 12px 24px;outline:0px;padding:0px;vertical-align:baseline;list-style:none"><li class="m_7654275773649816155item" style="border:0px;margin:0px;outline:0px;padding:0px 0px 0px 1.3em;vertical-align:baseline;list-style-type:none"><p class="m_7654275773649816155para" style="border:0px;margin:0px;outline:0px;padding:0px 0px 6px;vertical-align:baseline;line-height:24.360000610351563px"><span style="background-color:rgba(255,255,255,0)"><em style="border:0px;margin:0px;outline:0px;padding:0px;vertical-align:baseline">"Private access</em> restricts the use of an entity to the enclosing declaration, and to extensions of that declaration that are in the same file. Use private access to hide the implementation details of a specific piece of functionality when those details are used only within a single declaration."</span></p><p class="m_7654275773649816155para" style="border:0px;margin:0px;outline:0px;padding:0px 0px 6px;vertical-align:baseline;line-height:24.360000610351563px"><br></p></li></ul></div>So... a private extension where the main entity is in the same file has its members act as "fileprivate", but (we can infer that) a private extension where the main entity is NOT in the same file should have its members act as "private". </div><div></div></div></blockquote><div dir="auto"><br></div><div dir="auto">No, its members are fileprivate to the file in which the extension resides.</div><div dir="auto"><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div>Is that inference in accordance with the intentions of Swift's design?<br></div><div><br></div><div>If yes, then the compiler should enforce it. If not, then the documentation should be changed.</div></div></blockquote><div dir="auto"><br></div><div dir="auto">The documentation is correct. To interpret it, you must understand that extensions are not entities and therefore do not have accessibility of their own; an access modifier in front of “extension” acts only as a shorthand to set the default and maximum access level of contained members. This aspect of Swift is not up for change, only the question of what the “private” shorthand means.</div><div dir="auto"><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div></div></div></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div>Does that summarize the proposal?</div><div><br><div><span style="background-color:rgba(255,255,255,0)">--<br>C. Keith Ray</span><div><span style="background-color:rgba(255,255,255,0)"><br></span></div><div><span style="background-color:rgba(255,255,255,0)">* <a href="https://leanpub.com/wepntk" target="_blank">https://leanpub.com/wepntk</a> <- buy my book?<br>* </span><a href="http://www.thirdfoundationsw.com/keith_ray_resume_2014_long.pdf" target="_blank">http://www.thirdfoundationsw.com/keith_ray_resume_2014_long.pdf</a><span style="background-color:rgba(255,255,255,0)"><br>* <a href="http://agilesolutionspace.blogspot.com/" target="_blank">http://agilesolutionspace.blogspot.com/</a></span></div></div></div></div><div dir="auto"><div><br>On Oct 9, 2017, at 10:36 AM, Jose Cheyo Jimenez via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br><br></div><blockquote type="cite"><div><br><div><blockquote type="cite"><div>On Oct 9, 2017, at 9:17 AM, Vladimir.S via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:</div><br class="m_7654275773649816155Apple-interchange-newline"><div><div>On 07.10.2017 20:17, Nevin Brackett-Rozinsky via swift-evolution wrote:<br><blockquote type="cite">Two weeks ago I had a fairly strong opinion about “private extension” behavior. After following this discussion, I now have no opinion on the matter.<br>I would summarize the points on both sides as follows:<br>For the change:<br>• It is surprising to many people that members of a private extension are implicitly fileprivate. > • There is currently no way to make an extension whose members default to private.<br></blockquote><br>I'd add this:<br>* Current rule for 'private extension' can lead to bugs, when you expect that private methods will be 'true' private but they are fileprivate, so could be called from not-expected code in the same file. Inverse situation(when you need fileprivate but 'private extension' means 'true' private) - can't cause bugs, you'll be notified by the compiler if you need a 'wider' access level.<br>* The change will make the access-control rule for extensions simpler, not harder to understand.<br>* 'fileprivate' access level for methods in extension will be used by *intention*, not just because "this is how 'private extension' works". If I understand correctly, it is not the 'fileprivate' *keyword* we want to see less, but the fileprivate *access level*, which should be rare and intentional.<br></div></div></blockquote><div><br></div><div>Top level private *is* private. Swift did not make a distinction between top level private and fileprivate so why should the programmer have to choose?</div><div><br></div><div>If you explicitly declare something private at the top level you are going to get fileprivate semantics. This is how scope private works. If you disagree then that is a different conversation I think. If you wish for these not have an overlap then that is definitely a different proposal?</div><br><blockquote type="cite"><div><div><br><blockquote type="cite">Against the change:<br>• The proposal is source-breaking.<br>• The proposal makes “fileprivate” more common.<br></blockquote><br>It depends on what most of Swift developers *mean* when writing 'private extension' - if they actually need 'fileprivate extension' - then yes, we'll see it more in code. But if in most cases the *intention* is to have a bunch of 'true private' methods - we'll have a small number of 'fileprivate extension'.<br>But in any case, what is the problem with this? If developer *needs* fileprivate access level for methods in extension - this will be clearly stated in code, not hidden under the cute title of 'private extension'<br><br><blockquote type="cite">• A private extension and a (top-level) private type both currently have implicitly fileprivate members. The proposal breaks that symmetry.<br></blockquote><br>Is it really good symmetry?<br>By definition, the rule for applying the access level to type is differ from the rule for extension. Here all symmetry already broken and we have 2 separate rules. And from my point of view, having a symmetry in *this particular* case is a bad thing, it can lead to wrong assumptions. Don't you want to apply the same 'symmetry' rule for the code below ? :<br></div></div></blockquote><div><br></div><div>I would be totally on board with making extensions work the same as types. So instead of enforcing a default ACL, the extension would work the same way as a type by just declaring the upper bound. This would effectively only allow extension to lower the upper bound while still making the default ACL to internal. This would also be a breaking change for public extensions that assume their members to be public. I believe that the behavior of public extension is more harmful and more likely to cause bugs because you are exposing a public API and may not be aware of it. This would remove the ability of open types to be extended with a default ACL of public. The same would happen to public types that are being extended with public modifier.</div><div><br></div><div>The below would be symmetrical but now public extension are essentially the same as just extension without the modifier.</div><div><br></div><div><pre style="box-sizing:border-box;font-family:SFMono-Regular,Consolas,'Liberation Mono',Menlo,Courier,monospace;font-size:11.9px;margin-top:0px;margin-bottom:0px;word-wrap:normal;padding:16px;overflow:auto;line-height:1.45;background-color:rgb(246,248,250);border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px;word-break:normal;color:rgb(36,41,46);font-variant-ligatures:normal"><span class="m_7654275773649816155pl-k" style="box-sizing:border-box;color:rgb(215,58,73)">open</span> <span class="m_7654275773649816155pl-k" style="box-sizing:border-box;color:rgb(215,58,73)">class</span> <span class="m_7654275773649816155pl-en" style="box-sizing:border-box;color:rgb(111,66,193)">MyOpenClass</span> {}
<span class="m_7654275773649816155pl-k" style="box-sizing:border-box;color:rgb(215,58,73)">public</span> <span class="m_7654275773649816155pl-k" style="box-sizing:border-box;color:rgb(215,58,73)">extension</span> <span class="m_7654275773649816155pl-en" style="box-sizing:border-box;color:rgb(111,66,193)">MyOpenClass</span> { <span class="m_7654275773649816155pl-c" style="box-sizing:border-box;color:rgb(106,115,125)"><span class="m_7654275773649816155pl-c" style="box-sizing:border-box">//</span> upper bound public</span>
<span class="m_7654275773649816155pl-c" style="box-sizing:border-box;color:rgb(106,115,125)"></span> <span class="m_7654275773649816155pl-k" style="box-sizing:border-box;color:rgb(215,58,73)">func</span> <span class="m_7654275773649816155pl-en" style="box-sizing:border-box;color:rgb(111,66,193)">myFunc</span>(){} <span class="m_7654275773649816155pl-c" style="box-sizing:border-box;color:rgb(106,115,125)"><span class="m_7654275773649816155pl-c" style="box-sizing:border-box">//</span> default internal, upperbound higher it stays internal. </span>
<span class="m_7654275773649816155pl-c" style="box-sizing:border-box;color:rgb(106,115,125)"></span>}
<span class="m_7654275773649816155pl-k" style="box-sizing:border-box;color:rgb(215,58,73)">internal</span> <span class="m_7654275773649816155pl-k" style="box-sizing:border-box;color:rgb(215,58,73)">extension</span> <span class="m_7654275773649816155pl-en" style="box-sizing:border-box;color:rgb(111,66,193)">MyOpenClass</span> { <span class="m_7654275773649816155pl-c" style="box-sizing:border-box;color:rgb(106,115,125)"><span class="m_7654275773649816155pl-c" style="box-sizing:border-box">//</span> upper bound internal</span>
<span class="m_7654275773649816155pl-c" style="box-sizing:border-box;color:rgb(106,115,125)"></span> <span class="m_7654275773649816155pl-k" style="box-sizing:border-box;color:rgb(215,58,73)">func</span> <span class="m_7654275773649816155pl-en" style="box-sizing:border-box;color:rgb(111,66,193)">myFunc2</span>(){} <span class="m_7654275773649816155pl-c" style="box-sizing:border-box;color:rgb(106,115,125)"><span class="m_7654275773649816155pl-c" style="box-sizing:border-box">//</span> default internal</span>
<span class="m_7654275773649816155pl-c" style="box-sizing:border-box;color:rgb(106,115,125)"></span>}
<span class="m_7654275773649816155pl-k" style="box-sizing:border-box;color:rgb(215,58,73)">fileprivate</span> <span class="m_7654275773649816155pl-k" style="box-sizing:border-box;color:rgb(215,58,73)">extension</span> <span class="m_7654275773649816155pl-en" style="box-sizing:border-box;color:rgb(111,66,193)">MyOpenClass</span> { <span class="m_7654275773649816155pl-c" style="box-sizing:border-box;color:rgb(106,115,125)"><span class="m_7654275773649816155pl-c" style="box-sizing:border-box">//</span> upper bound fileprivate</span>
<span class="m_7654275773649816155pl-c" style="box-sizing:border-box;color:rgb(106,115,125)"></span> <span class="m_7654275773649816155pl-k" style="box-sizing:border-box;color:rgb(215,58,73)">func</span> <span class="m_7654275773649816155pl-en" style="box-sizing:border-box;color:rgb(111,66,193)">myFunc3</span>(){} <span class="m_7654275773649816155pl-c" style="box-sizing:border-box;color:rgb(106,115,125)"><span class="m_7654275773649816155pl-c" style="box-sizing:border-box">//</span> default internal but lowered to fileprivate</span>
<span class="m_7654275773649816155pl-c" style="box-sizing:border-box;color:rgb(106,115,125)"></span>}
<span class="m_7654275773649816155pl-k" style="box-sizing:border-box;color:rgb(215,58,73)">private</span> <span class="m_7654275773649816155pl-k" style="box-sizing:border-box;color:rgb(215,58,73)">extension</span> <span class="m_7654275773649816155pl-en" style="box-sizing:border-box;color:rgb(111,66,193)">MyOpenClass</span> { <span class="m_7654275773649816155pl-c" style="box-sizing:border-box;color:rgb(106,115,125)"><span class="m_7654275773649816155pl-c" style="box-sizing:border-box">//</span> upper bound toplevel private</span>
<span class="m_7654275773649816155pl-c" style="box-sizing:border-box;color:rgb(106,115,125)"></span> <span class="m_7654275773649816155pl-k" style="box-sizing:border-box;color:rgb(215,58,73)">func</span> <span class="m_7654275773649816155pl-en" style="box-sizing:border-box;color:rgb(111,66,193)">myFunc4</span>(){} <span class="m_7654275773649816155pl-c" style="box-sizing:border-box;color:rgb(106,115,125)"><span class="m_7654275773649816155pl-c" style="box-sizing:border-box">//</span> default internal but lowered to toplevel private</span>
<span class="m_7654275773649816155pl-c" style="box-sizing:border-box;color:rgb(106,115,125)"></span>}</pre><div><br></div></div><div><br></div><br><blockquote type="cite"><div><div><br>public class C {<br> var i = 10<br>}<br><br>public extension C {<br> func j(){}<br>}<br><br>,as you understand 'i' is internal, while 'j()' is public. So this could be a dangerous assumption.<br><br><br><blockquote type="cite">Notable questions:<br>• Currently “open” cannot be applied to an extension at all, should we allow it?<br></blockquote><br>Probably. But this should be a separate pitch/proposal.<br><br><blockquote type="cite">• Might we ever want to allow nested (non-top level) extensions, and if so how should access levels on them work?<br></blockquote><br>Not sure if we need them, this is also a subject for separate pitch/proposal.<br>But if the rule for applying the access level for extension will be as currently(I don't believe we'll change it soon) - nested extensions should work the same "the access level keyword stated before the 'extension' keyword will be virtually copy&pasted to the beginning of each method declaration inside extension and then resolved", IMO this is a most clear rule we can have *in case rule for extensions is differ from rule for type”.<br></div></div></blockquote><div><br></div><div> “keyword will be virtually copy&pasted “ sound to me more like extension should take a parameter like ‘extension(private)’ or similar. Explicit declaration of a keyword should take precedence at the location that it was declare. </div><div><br></div><div><br></div><blockquote type="cite"><div><div><br>Vladimir.<br><br><blockquote type="cite">Nevin<br>_______________________________________________<br>swift-evolution mailing list<br><a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br></blockquote>_______________________________________________<br>swift-evolution mailing list<br><a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br></div></div></blockquote></div><br></div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>swift-evolution mailing list</span><br><span><a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></div></blockquote></div>_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</blockquote></div></div>