<html><head></head><body><div>What about local for a file only or scope definition ?&nbsp;<br><br><div class="acompli_signature">Sent from <a dir="ltr" href="http://supmenow.com" x-apple-data-detectors="true" x-apple-data-detectors-type="link" x-apple-data-detectors-result="0">Supmenow.com</a></div><br></div><br><br><br>
<div class="gmail_quote">On Wed, Mar 30, 2016 at 12:39 PM -0700, "Jordan Rose via swift-evolution" <span dir="ltr">&lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt;</span> wrote:<br>
<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">




<div dir="3D&quot;ltr&quot;">
<meta http-equiv="Content-Type" content="text/html charset=utf-8"><div class="">Ah, sorry! Those are all clear to me; it's the possibility of writing some <i class="">other</i>&nbsp;module name there that would have the wrong implications.</div><div class=""><br class=""></div><div class="">Jordan</div><br class=""><div><blockquote type="cite" class=""><div class="">On Mar 30, 2016, at 12:38 , Ross O'Brien &lt;<a href="mailto:narrativium+swift@gmail.com" class="">narrativium+swift@gmail.com</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class="">Damn, and I thought it was clear all this time that 'private(module)', or 'private(#module)', or 'moduleprivate', meant that the symbol is visible only inside the module. It's always been a suggested replacement specifier for 'internal'.</div></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Wed, Mar 30, 2016 at 6:33 PM, Jordan Rose via swift-evolution <span dir="ltr" class="">&lt;<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>&gt;</span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><span class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Mar 29, 2016, at 17:47 , Brent Royal-Gordon &lt;<a href="mailto:brent@architechies.com" target="_blank" class="">brent@architechies.com</a>&gt; wrote:</div><br class=""><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 style="white-space:pre-wrap" class="">        </span>public<span style="white-space:pre-wrap" class="">        </span><span style="white-space:pre-wrap" class="">        </span><span style="white-space:pre-wrap" class="">        </span><span style="white-space:pre-wrap" class="">        </span><span style="white-space:pre-wrap" class="">        </span><span style="white-space:pre-wrap" class="">        </span><span style="white-space:pre-wrap" class="">        </span>// visible to all everyone<br class=""><span style="white-space:pre-wrap" class="">        </span>private(scope-name, scope-name, …) <span style="white-space:pre-wrap" class="">        </span>// visible to specified scopes (plus current scope)<br class=""><span style="white-space:pre-wrap" class="">        </span>private<span style="white-space:pre-wrap" class="">        </span><span style="white-space:pre-wrap" class="">        </span><span style="white-space:pre-wrap" class="">        </span><span style="white-space:pre-wrap" class="">        </span><span style="white-space:pre-wrap" class="">        </span><span style="white-space:pre-wrap" class="">        </span><span style="white-space:pre-wrap" class="">        </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=""></span><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>&nbsp;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>&nbsp;public". The restriction on use sites is an artificial one.</div><div class=""><br class=""></div><div class="">Now, it <i class="">is</i>&nbsp;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>&nbsp;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>&nbsp;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>&nbsp;file, and then…</div><div class=""><br class=""></div><div class="">Jordan</div></div><br class="">_______________________________________________<br class="">
swift-evolution mailing list<br class="">
<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="">
<br class=""></blockquote></div><br class=""></div>
</div></blockquote></div><br class="">
</div>

</blockquote>
</div>
</body></html>