<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=""><div class=""><blockquote type="cite" class=""></blockquote><blockquote type="cite" class=""><blockquote type="cite" class="">The reason internal or private can't be called from outside an executable is that no data about it exists in the final executable<br class=""></blockquote><br class="">Actually, I believe internal symbols *are* in the final executable. (If they aren't now, they certainly were for a while.)</blockquote></div><div class=""><br class=""></div><div class="">The LLVM bitcode for internal symbols has the <a href="http://llvm.org/docs/LangRef.html#visibilitystyles" class="">"hidden" visibility style</a> (you can test with swift -emit-ir). It's possible that the symbol will show up in debug executables, but the intent is to get rid of it at release.</div><br class=""><div><blockquote type="cite" class=""><div class="">Le 12 janv. 2016 à 00:28:55, <a href="mailto:cocoadev@charlessoft.com" class="">cocoadev@charlessoft.com</a> a écrit :</div><div class=""><div class=""><blockquote type="cite" class="">The great thing about using the linker to implement access control is<br class="">that it can be enforced. The reason internal or private can't be<br class="">called from outside an executable is that no data about it exists in<br class="">the final executable As a matter of fact, the symbol itself might not<br class="">even exist in the fully optimized executable.<br class=""></blockquote><br class="">Access modifiers aren't just across linker boundaries. Private, private(set), and, if implemented, private(call) would help enforce boundaries between classes within a single module as well.<br class=""></div></div></blockquote><div><br class=""></div><div>Currently, access modifiers *are* just across linker boundaries. The translation unit (single file) level is a linker boundary. Private is very close to C's static.</div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><blockquote type="cite" class="">I also think that it's fundamentally the same as protected, because<br class="">nothing prevents you from sharing the logic outside. You can forward<br class="">the protected call to a public call, which is exactly the same as a<br class="">public call forwarding to a protected call in terms of encapsulation.<br class=""></blockquote><br class="">Um, if that's your metric, then private is fundamentally the same as internal is the same as public, and there's no such thing as access modifiers at all. *Anything* can be forwarded to a public call, whether it's private, public, internal, my proposed private(call), or protected, if it's done within the class that owns it. However, code from outside the class (or struct, or enum, or whatever) wouldn't be able to access something defined as private(call), even if it's a class and they're a subclass of it, whereas with protected, if you're a subclass it's basically open season.<br class=""></div></div></blockquote><div><br class=""></div>They're not, because as the writer of the Swift library, *you* are in control of internal and private members. I believe that the worry has never been what you could do with your own code, but rather what others can do with your own code, and in the case of a `private(call)` member, if the person really wants that logic to be callable, they have means to do it (whereas they don't have the means to call an internal or private symbol).<div><span style="font-family: LucidaGrande;" class=""><br class=""></span></div><div><span style="font-family: LucidaGrande;" class="">The only un-abusable justification for the feature is to document that a symbol shouldn't be used directly, hence the suggestion to use documentation features to achieve that goal.</span></div></div></body></html>