<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="">Maybe it's because I know too much about it, but to me, private(extension) doesn't follow the spirit of private(set).<div class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class=""><div class=""><div class=""><div class=""><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; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; display: inline !important; float: none;" class="">Félix</span>
</div>
<br class=""><div><blockquote type="cite" class=""><div class="">Le 5 janv. 2016 à 19:59:11, Austin Zheng via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> a écrit :</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">Hi all,<div class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class="">- 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 class="">- 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 class="">- 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 class="">- 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 class=""><br class=""></div><div class="">I think this is a reasonably elegant, small-surface-area solution to a common problem, but I can see some potential objections:</div><div class=""><br class=""></div><div class="">- It adds some complexity to the access control subsystem. Maybe that subsystem is complex enough as is.</div><div class="">- 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 class="">- Maybe there might be more elegant ways to improve or extend the access control subsystem.</div><div class=""><br class=""></div><div class="">Any thoughts?</div><div class=""><br class=""></div><div class="">Best,</div><div class="">Austin</div></div>
<img src="https://u2002410.ct.sendgrid.net/wf/open?upn=iRI3beHTe3UxYAHTlV3lA38zIPfHMhyuRzgTmGKV6k6AxR9XU4Ydv5uyo28HN4dr1mwc8HycprQLQx1zE2bi-2BN-2BL1P2IGg8OuoMEHEPssShwJMHjWNnGMqy5hDHGlogh3x1hlGjzCnQrbGk8kAoDtpbGAghDgYxkK9voikuN2fJDzyB483Oehj2jN0UlCkjuUrNJ7QVgU7Bw9TDIMmX237Ee5gDVfPYvgHQSRSVr62U-3D" alt="" width="1" height="1" border="0" style="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;" class="">
_______________________________________________<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></div></body></html>