<div dir="ltr">I see your point, and I think it's a good one. I'm don'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"><<a href="mailto:felixcca@yahoo.ca" target="_blank">felixcca@yahoo.ca</a>></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's because I know too much about it, but to me, private(extension) doesn't follow the spirit of private(set).<div><br></div><div>In Swift, access modifiers are tied to the linker's notion of symbol visibility. Private symbols are accessible only within the current file because they're not exported at all. Internal symbols are accessible only within the module because they don't make it to the public symbol table. When you have private(set), all you're saying is "make the setter private", 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't be cluttered with private(extension) members in files that don't extend the class. Because of that, I don'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'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:'Lucida Grande';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 <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> 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 'private' can't be seen from other files.</div><div><br></div><div>I'd like to suggest an access modifier: "private(extension)". This follows in the spirit of the existing "private(set)" 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 "private" today.</div><div>- A member declared private(set) would be visible in any file containing an extension to the member'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 "private(set, extension)".</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>