<div dir="ltr">I see your point, and I think it&#39;s a good one. I&#39;m don&#39;t think this proposal is worth pursuing further, although I would like some notion of more flexible access control in the future.<br><div><br></div><div>Thanks,</div><div>Austin</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jan 5, 2016 at 5:47 PM, Félix Cloutier <span dir="ltr">&lt;<a href="mailto:felixcca@yahoo.ca" target="_blank">felixcca@yahoo.ca</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">Maybe it&#39;s because I know too much about it, but to me, private(extension) doesn&#39;t follow the spirit of private(set).<div><br></div><div>In Swift, access modifiers are tied to the linker&#39;s notion of symbol visibility. Private symbols are accessible only within the current file because they&#39;re not exported at all. Internal symbols are accessible only within the module because they don&#39;t make it to the public symbol table. When you have private(set), all you&#39;re saying is &quot;make the setter private&quot;, and this is easy.</div><div><br></div><div>In general, your definition of private(extension) makes it identical to internal, except that autocomplete won&#39;t be cluttered with private(extension) members in files that don&#39;t extend the class. Because of that, I don&#39;t think that it adds a lot of technical complexity to access control, but it also makes me think that it might not be worth it.</div><div><br></div><div>Since private(extension) can be (ab)used to make any member internal, I wonder if we couldn&#39;t fix this with finer-grained autocomplete or something instead.</div><div><br></div><div><div><div><div><span style="color:rgb(0,0,0);font-family:&#39;Lucida Grande&#39;;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;display:inline!important;float:none">Félix</span>
</div>

<br><div><blockquote type="cite"><div><div class="h5"><div>Le 5 janv. 2016 à 19:59:11, Austin Zheng via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt; a écrit :</div><br></div></div><div><div><div class="h5"><div dir="ltr">Hi all,<div><br></div><div>One popular use of extensions is to take the definition of a type (e.g. MyBigClass) and to split it up over a number of files, grouping related methods together for increased code comprehensibility. However, access control makes doing so more difficult: members that are implementation details and declared as &#39;private&#39; can&#39;t be seen from other files.</div><div><br></div><div>I&#39;d like to suggest an access modifier: &quot;private(extension)&quot;. This follows in the spirit of the existing &quot;private(set)&quot; for properties. It would work in the following way:</div><div><br></div><div>- A member declared private(set) would be visible throughout the file within which it was declared, exactly as if it had been declared &quot;private&quot; today.</div><div>- A member declared private(set) would be visible in any file containing an extension to the member&#39;s type, throughout the entire file.</div><div>- This would only work for extensions to types declared within the same module; it would not be meant as a way to expose impl details to other modules or application code consuming the module.</div><div>- A property in T meant to be only gettable from other files, but settable from extensions to T in other files, would be declared &quot;private(set, extension)&quot;.</div><div><br></div><div>I think this is a reasonably elegant, small-surface-area solution to a common problem, but I can see some potential objections:</div><div><br></div><div>- It adds some complexity to the access control subsystem. Maybe that subsystem is complex enough as is.</div><div>- It might leak implementation details of a type T to code belonging to another type or global function, residing within the same file as an extension to T.</div><div>- Maybe there might be more elegant ways to improve or extend the access control subsystem.</div><div><br></div><div>Any thoughts?</div><div><br></div><div>Best,</div><div>Austin</div></div>
</div></div><img src="https://u2002410.ct.sendgrid.net/wf/open?upn=iRI3beHTe3UxYAHTlV3lA38zIPfHMhyuRzgTmGKV6k6AxR9XU4Ydv5uyo28HN4dr1mwc8HycprQLQx1zE2bi-2BN-2BL1P2IGg8OuoMEHEPssShwJMHjWNnGMqy5hDHGlogh3x1hlGjzCnQrbGk8kAoDtpbGAghDgYxkK9voikuN2fJDzyB483Oehj2jN0UlCkjuUrNJ7QVgU7Bw9TDIMmX237Ee5gDVfPYvgHQSRSVr62U-3D" alt="" width="1" height="1" border="0" style="min-height:1px!important;width:1px!important;border-width:0!important;margin-top:0!important;margin-bottom:0!important;margin-right:0!important;margin-left:0!important;padding-top:0!important;padding-bottom:0!important;padding-right:0!important;padding-left:0!important">
_______________________________________________<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></blockquote></div><br></div></div></div></div></blockquote></div><br></div>