<html><body><div>public<br></div><div><a href="mailto:private@module">private@module</a><br data-mce-bogus="1"></div><div><a href="mailto:private@file">private@file</a><br data-mce-bogus="1"></div><div>private<br data-mce-bogus="1"></div><div><br></div><div>or<br data-mce-bogus="1"></div><div><br></div><div>public<br data-mce-bogus="1"></div><div>private-module<br data-mce-bogus="1"></div><div>private-file<br data-mce-bogus="1"></div><div>private<br><div><br data-mce-bogus="1"></div><div>or<br data-mce-bogus="1"></div><div><br></div><div>public<br data-mce-bogus="1"></div><div>private/module<br data-mce-bogus="1"></div><div>private/file<br data-mce-bogus="1"></div><div>private<br data-mce-bogus="1"></div></div><div><br></div><div>or some other separating character.<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><div>This would allow <a href="mailto:private@module(set)">private@module(set)</a> or private-module(set) or private/module(set)<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><div>Actually I tend to the last one using the slash.<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><div>-Thorsten<br data-mce-bogus="1"></div><div><br>Am 15. März 2016 um 04:36 schrieb Patrick Pijnappel via swift-evolution &lt;swift-evolution@swift.org&gt;:<br><br><div><blockquote type="cite"><div class="msg-quote"><div dir="ltr">Another +1 for James' idea to use private(module), private(file), private:<br><div>- It avoids ambiguity whether internal/private/local is more restrictive and replaces it with a single axis, public vs. private.<br></div><div>- The two longer terms, private(module) and private(file), are the least used ones.</div><div>- As mentioned by Joe, it admits clean extension to groupings between file and modules in the future (e.g. submodules).</div><div><br></div><div>The only question is (as Sean mentioned) how this combines with the syntax for setter access level, e.g. the current private(set). Options:</div><div>- Unnamed 2nd argument, giving private(file), private(file, set), private(set).</div><div>- Named 2nd argument, giving e.g. private(file), private(file, accessor: set), private(accessor: set). Less ambiguity but longer.</div><div>- Not using multiple arguments, but that'd probably break consistency with the other unification efforts going on to make everything look like function calls.</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Mar 15, 2016 at 1:42 PM, Sean Heber via swift-evolution <span dir="ltr">&lt;<a href="mailto:swift-evolution@swift.org" data-mce-href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin: 0 0 0 0.8ex; border-left: 1px #ccc solid; padding-left: 1ex;" data-mce-style="margin: 0 0 0 0.8ex; border-left: 1px #ccc solid; padding-left: 1ex;">Although really, why not just use “file” instead of “internal” since it won’t burn any keywords or cause any other conflicts as far as I know.<br> <br> l8r<br> Sean<br><div class="HOEnZb"><div class="h5"><br> <br> &gt; On Mar 14, 2016, at 9:38 PM, Sean Heber &lt;<a href="mailto:sean@fifthace.com" data-mce-href="mailto:sean@fifthace.com">sean@fifthace.com</a>&gt; wrote:<br> &gt;<br> &gt; I, too, prefer it to be more like this:<br> &gt;<br> &gt; public&nbsp; // unchanged<br> &gt; module&nbsp; // currently internal<br> &gt; internal&nbsp; // currently private<br> &gt; private&nbsp; // new hotness<br> &gt;<br> &gt; l8r<br> &gt; Sean<br> &gt;<br> &gt;<br> &gt;&gt; On Mar 14, 2016, at 7:50 PM, Jo Albright via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" data-mce-href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>&gt; wrote:<br> &gt;&gt;<br> &gt;&gt; +1<br> &gt;&gt;<br> &gt;&gt; I like this a lot. Name ideas : enclosed, filelocal, fileonly, filelock, fileaccess, fileprivate, insidefile, inner. I also like Erica’s filebound &amp; file fixed.<br> &gt;&gt;<br> &gt;&gt; By Erica’s suggestion about switching…<br> &gt;&gt;<br> &gt;&gt; - public<br> &gt;&gt; - modular, modulelock, packaged&nbsp; (module only)<br> &gt;&gt; - internal (file only)<br> &gt;&gt; - private<br> &gt;&gt;<br> &gt;&gt; Designer . Developer .  Nerd<br> &gt;&gt; Jo Albright<br> &gt;&gt;<br> &gt;&gt;<br> &gt;&gt;&gt; On Mar 14, 2016, at 8:18 PM, Chris Lattner via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" data-mce-href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>&gt; wrote:<br> &gt;&gt;&gt;<br> &gt;&gt;&gt; Per Doug’s email, the core team agrees we should make a change here, but would like some bikeshedding to happen on the replacement name for private.<br> &gt;&gt;&gt;<br> &gt;&gt;&gt; To summarize the place we’d like to end up:<br> &gt;&gt;&gt;<br> &gt;&gt;&gt; - “public” -&gt; symbol visible outside the current module.<br> &gt;&gt;&gt; - “internal” -&gt; symbol visible within the current module.<br> &gt;&gt;&gt; - unknown -&gt; symbol visible within the current file.<br> &gt;&gt;&gt; - “private” -&gt; symbol visible within the current declaration (class, extension, etc).<br> &gt;&gt;&gt;<br> &gt;&gt;&gt; The rationale here is that this aligns Swift with common art seen in other languages, and that many people using private today don’t *want* visibility out of their current declaration.&nbsp; It also encourages “extension oriented programming”, at least it will when some of the other restrictions on extensions are lifted.&nbsp; We discussed dropping the third one entirely, but think it *is* a useful and important level of access control, and when/if we ever get the ability to write unit tests inside of the file that defines the functionality, they will be a nicer solution to @testable.<br> &gt;&gt;&gt;<br> &gt;&gt;&gt; The thing we need to know is what the spelling should be for the third one.&nbsp; Off hand, perhaps:<br> &gt;&gt;&gt;<br> &gt;&gt;&gt; fileprivate<br> &gt;&gt;&gt; private(file)<br> &gt;&gt;&gt; internal(file)<br> &gt;&gt;&gt; fileaccessible<br> &gt;&gt;&gt; etc<br> &gt;&gt;&gt;<br> &gt;&gt;&gt; Some other thoughts on the choice:<br> &gt;&gt;&gt; - this will be a declaration modifier, so it will not “burn” a keyword.<br> &gt;&gt;&gt; - if will be a uniquely Swift thing, so there is virtue in it being a googlable keyword.<br> &gt;&gt;&gt;<br> &gt;&gt;&gt; Thoughts appreciated.<br> &gt;&gt;&gt;<br> &gt;&gt;&gt; -Chris<br> &gt;&gt;&gt;<br> &gt;&gt;&gt; _______________________________________________<br> &gt;&gt;&gt; swift-evolution mailing list<br> &gt;&gt;&gt; <a href="mailto:swift-evolution@swift.org" data-mce-href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br> &gt;&gt;&gt; <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" data-mce-href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br> &gt;&gt;<br> &gt;&gt; _______________________________________________<br> &gt;&gt; swift-evolution mailing list<br> &gt;&gt; <a href="mailto:swift-evolution@swift.org" data-mce-href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br> &gt;&gt; <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" data-mce-href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br> &gt;<br> <br> _______________________________________________<br> swift-evolution mailing list<br> <a href="mailto:swift-evolution@swift.org" data-mce-href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" data-mce-href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br></div></div></blockquote></div><br></div><div class="_stretch"><span class="body-text-content">_______________________________________________<br>swift-evolution mailing list<br><a href="mailto:swift-evolution@swift.org" data-mce-href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" data-mce-href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br></span></div></div></blockquote></div></div></body></html>