<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=""><br class=""><div><blockquote type="cite" class=""><div class="">On Mar 29, 2016, at 17:47 , Brent Royal-Gordon <<a href="mailto:brent@architechies.com" class="">brent@architechies.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class=""><blockquote type="cite" class="">If Scala style access modifiers were adopted for Swift then a private(file) modifier would also be necessary to give the current private functionality.<br class=""></blockquote><br class="">I could imagine having these options:<br class=""><br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>public<span class="Apple-tab-span" style="white-space:pre"> </span><span class="Apple-tab-span" style="white-space:pre"> </span><span class="Apple-tab-span" style="white-space:pre"> </span><span class="Apple-tab-span" style="white-space:pre"> </span><span class="Apple-tab-span" style="white-space:pre"> </span><span class="Apple-tab-span" style="white-space:pre"> </span><span class="Apple-tab-span" style="white-space:pre"> </span>// visible to all everyone<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>private(scope-name, scope-name, …) <span class="Apple-tab-span" style="white-space:pre"> </span>// visible to specified scopes (plus current scope)<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>private<span class="Apple-tab-span" style="white-space:pre"> </span><span class="Apple-tab-span" style="white-space:pre"> </span><span class="Apple-tab-span" style="white-space:pre"> </span><span class="Apple-tab-span" style="white-space:pre"> </span><span class="Apple-tab-span" style="white-space:pre"> </span><span class="Apple-tab-span" style="white-space:pre"> </span><span class="Apple-tab-span" style="white-space:pre"> </span>// visible only to current scope<br class=""><br class="">scope-name could perhaps be:<br class=""><br class="">* A type name (or Self, which would mimic C++-style private, or perhaps even C++-style protected depending on how we treat inheritance)<br class="">* A module name (or #module for the current module)<br class="">* A file name string (or #file for the current file)<br class=""><br class="">And then the default would simply be `private(#module)`.<br class=""><br class="">Alternatively, the parameterized level could be given a different name, like `internal` or `shared`. If that were the case, then `#module` might simply be the default.<br class=""></div></div></blockquote></div><br class=""><div class="">I've actually thought about this before (well, at least at the module level) and ultimately decided it was a bad idea for it to be part of the access control system. Why? Because there's nothing "private" about sharing with another module, even if it's just <i class="">one</i> other module.</div><div class=""><br class=""></div><div class="">- You don't get any secrecy because you have to publish all symbols and metadata as public.</div><div class="">- You can't optimize based on knowledge of how the declaration is used.</div><div class="">- Exposing something to another module can be viral, just like making something 'public' would be viral: all of a type's protocol conformances are exposed, a class's superclass must be exposed, all the types in a function signature have to be exposed (or already public).</div><div class=""><br class=""></div><div class="">All of this means that this behaves more like "public" than like "private"; it's "public, but not the <i class="">entire</i> public". The restriction on use sites is an artificial one.</div><div class=""><br class=""></div><div class="">Now, it <i class="">is</i> a very useful feature! Apple, of course, does this all the time with its "SPI". But I think the right form of the feature is to be able to tag a bunch of public declarations as "SPI" or "limited" or "limited to group 'X'" or possibly even "limited to module 'X'", and then have a tool to <i class="">strip them out</i> of the swiftmodule file when you're ready to ship this module to people. That way you're enforcing your limitations as much as possible, while still using the same binaries for both internal and external clients. (Remember that the swiftmodule file serves essentially the same purpose as header files in C.)</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">At the file level, there's nothing inherently wrong with this idea, but I don't think there's enough gain to writing file strings directly in source files. Pointing to a future "comprehensive submodules model" would be disingenuous because that's a <i class="">huge</i> feature with a lot of subtlety, but I think "just make this accessible to one other file" is additional complexity for not much gain. It's also subject to slippery-slope: once one file is added, I don't think anyone would think too hard about adding a <i class="">second</i> file, and then…</div><div class=""><br class=""></div><div class="">Jordan</div></body></html>