<div dir="ltr"><div>Well, several prominent voices seem to think that &#39;private&#39; is &quot;intuitively obvious&quot; when it refers to declaration-level scope, so I didn&#39;t argue that point. I still happen to disagree; I would add &#39;privatetodeclaration&#39; to &#39;privatetomodule&#39; and &#39;privatetofile&#39;, which would solve that conversational point: &quot;These properties are private to the declaration&quot;.</div><div><br></div><div>Alternatively: &#39;fileaccessible&#39;, &#39;moduleaccessible&#39;, &#39;declarationaccessible&#39;? (Does that confuse code accessibility with such things as UIAccessibility?)</div><div><br></div><div>That doesn&#39;t answer your awkward-to-read-in-code problem. I don&#39;t have a solution to that.</div><div><br></div><div>To re-specify the problem, again (perhaps more for my benefit while writing as yours while reading): the terms we choose have to suggest accessibility, but a subjective spectrum of adjectives does not give us clarity. The idea of building into these symbols references to exactly where the scope ends appears to be popular. There aren&#39;t any existing one-word terms which express these concepts so we&#39;re coining new words out of two (or more) existing words. Which combination of words is least awkward to read, or most intuitive to type, is still going to be subjective.</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Mar 25, 2016 at 4:29 PM, Jordan Rose <span dir="ltr">&lt;<a href="mailto:jordan_rose@apple.com" target="_blank">jordan_rose@apple.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div>It doesn&#39;t solve the problem for me. &quot;These properties are private.&quot; &quot;To what?&quot; &quot;Just private&quot; / &quot;To the scope&quot;.</div><div><br></div><div>They&#39;re also still awkward to read in code. I know we have lots of decl modifiers, but I&#39;ve convinced myself we&#39;re not in Java&#39;s &quot;public static void main&quot; soup situation yet.</div><span class="HOEnZb"><font color="#888888"><div><br></div><div>Jordan</div></font></span><div><div class="h5"><div><br></div><br><div><blockquote type="cite"><div>On Mar 25, 2016, at 9:27 , Ross O&#39;Brien &lt;<a href="mailto:narrativium+swift@gmail.com" target="_blank">narrativium+swift@gmail.com</a>&gt; wrote:</div><br><div><div dir="ltr">Well... how about we reverse the terms: call them &#39;privatetomodule&#39; and &#39;privatetofile&#39;.<div><br></div><div>This is &#39;private(module)&#39; and &#39;private(file)&#39; but fitting the all lower-case style. It puts &#39;private&#39; first (and when you use the keyword, &#39;private&#39; is the bit you want to start with more than &#39;module&#39; or &#39;file&#39;). It&#39;s easier to use in conversation (&quot;these properties are private to the file&quot;).</div><div>Disadvantage: it adds &#39;to&#39;, so the words are even longer (but no longer than the parenthesised form would&#39;ve taken).</div><div><br></div><div>&#39;privatetofile extension Foo : BarConvertible { }&#39;</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Mar 25, 2016 at 4:15 PM, 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><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><span><br><div><blockquote type="cite"><div>On Mar 24, 2016, at 16:20 , Erica Sadun via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt; wrote:</div><br><div><blockquote type="cite" style="font-family:Monaco;font-size:11px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><br>On Mar 24, 2016, at 5:13 PM, Brent Royal-Gordon &lt;<a href="mailto:brent@architechies.com" target="_blank">brent@architechies.com</a>&gt; wrote:<br><br><blockquote type="cite">I think it does. `module` could mean many things related to how Swift creates and consumes modules.<span> </span><br>`moduleprivate` combines something about access levels (public/private) and scope (module), is easy to<span> </span><br>Google, offers few &quot;wrong&quot; interpretations. By using a longer keyword, it is less flexible in meaning and<span> </span><br>more fixed in purpose.<br></blockquote><br>Sure, but is that worth 7 to 9 extra characters at every single use site for something that&#39;s actually pretty common? Is it worth the muddled mess of an all-lowercase keyword with no obvious break, or the attention-grabbing of a capital letter or an underscore?<br><br>`module` and `file` are not going to be obscure corners of the language. Most people will probably learn about them at the same time they learn about `public` and `private`.<span> </span><br><br>(Actually, if `module` continues to be the default, you probably won&#39;t see it *that* often. You *will* see `file`, but that&#39;s the one that can&#39;t be as easily confused with a declaration.)<br><br>Obviousness for new users is great, but you can take it too far. We call the type `Int32`, not `SignedIntegerBetweenNegative2ToThe31stPowerAnd2ToThe31stPowerMinus1`—and if we did, it&#39;s not clear the longer name would really be more obvious, because it would be such a pain to read.<br></blockquote><br style="font-family:Monaco;font-size:11px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><br style="font-family:Monaco;font-size:11px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><span style="font-family:Monaco;font-size:11px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important">`moduleprivate` is the default value. I doubt it will get  used much if at all. I don&#39;t think `fileprivate` will get used much either</span><br style="font-family:Monaco;font-size:11px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><span style="font-family:Monaco;font-size:11px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important">but in such cases, I think those seven extra letters are essential and documenting.</span><br style="font-family:Monaco;font-size:11px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><br style="font-family:Monaco;font-size:11px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><span style="font-family:Monaco;font-size:11px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important">The two remaining public and private access levels are simple and intuitively obvious.</span><br style="font-family:Monaco;font-size:11px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"></div></blockquote></div><br></span><div>I&#39;m going to say that I remain unhappy with these new names. I don&#39;t believe that these won&#39;t get used, and I don&#39;t want them to feel awkward, discouraged, or penalized when they do. The standard library, for example, has in its style guide that all access control should be explicit, which is a reasonable style to enforce. I also have a small concern that they won&#39;t be easy to talk about: &quot;this method is private&quot; &quot;wait, file-private or module-private?&quot; &quot;neither, just private-private&quot;.</div><div><br></div><div>I realize these are all vague concerns, and I don&#39;t have something more concrete—or a better alternative. &quot;modulescoped&quot; and &quot;filescoped&quot; would be very literally accurate but (a) would force people to learn what &quot;scoped&quot; means unnecessarily, and (b) aren&#39;t less awkward.</div><div><br></div><div>I agree with the concerns that just saying &quot;file var foo&quot; makes it sound like there&#39;s one copy of the variable shared in the entire file, even when applied to an instance property. I think there&#39;s a lot of value is making the access control terms adjectives.</div><div><br></div><div>I honestly still think &quot;public, internal, private, local&quot; is a better taxonomy.. It&#39;s true that &quot;internal&quot; and &quot;private&quot; aren&#39;t automatically ordered relative to each other (and maybe not even &quot;local&quot;), but they&#39;re all adjectives (unlike &quot;module&quot; and &quot;file&quot;), and they&#39;re not awkward to read or to use in conversation. But both the core team and the list disagree, mainly because (a) it aligns &#39;private&#39; more closely with other languages, and (b) if you&#39;re not thinking about it, more restrictive is better than less. (Both of which I agree are good ideas.)</div><div><br></div><div>Jordan</div></div><br>_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
<br></blockquote></div><br></div>
</div></blockquote></div><br></div></div></div></blockquote></div><br></div>