<div dir="ltr">Isn&#39;t declaring &quot;scope&quot; access for a type at file-level effectively the same as &quot;internal&quot;?<div>All symbols I declare at top-level of a file have &quot;internal&quot; access by default.</div><div><br></div><div>For me &quot;public&quot;, &quot;internal&quot; and &quot;private&quot; ARE access <i>scopes</i> so adding &quot;scope&quot; as an additional access scope is somehow confusing.</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Dec 14, 2015 at 5:58 PM, Matthew Johnson 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">I agree that you can concoct arbitrarily complex scenarios and a line must be drawn somewhere.  IMO the best place to draw the line is when you start considering something that is not super straightforward to explain and is not a natural extension of the obviously necessary access modifiers.  <div><br></div><div>IMO ‘scope’ passes this test and all of the complex counter-examples do not.  It is the logical conclusion of a simple narrowing of visibility from “everyone” to “module” to “file” to “scope”.  It is simple to explain and understand.  Those who don’t like it don’t need to use it.  Anything more complex is unlikely to pass such a test.<div><br></div><div>Matthew</div><div><div class="h5"><div><br><div><blockquote type="cite"><div>On Dec 14, 2015, at 10:52 AM, David Owens II &lt;<a href="mailto:david@owensd.io" target="_blank">david@owensd.io</a>&gt; wrote:</div><br><div><div style="word-wrap:break-word">Let’s take this it’s next logical conclusion: I have two types that need to access each other’s members for some significant performance gain. Let’s call these types A and B. Now, A also needs access to the inner members for C for the same reason (but note that B does not). I currently have other related types all in the same file, let’s say D and E.<div><br></div><div>Now, all members should be “local” to the types, but remember, A needs to access B&#39;s and C&#39;s members and the other types do not. Also, I can’t simply move the them to different files because they have non-overlapping “local” usage requirements. So do I need to create a “local friend” modifier so only particular types can access the inner details?</div><div><br></div><div><div><div>There’s a line somewhere where complexity becomes more burdensome. I’m not sure if “local” is that line, but I absolutely do know that “local friend” is across that line (because of course we’ll need private friend and internal friend modifiers as well…).</div><div><br></div><div><blockquote type="cite"><div style="word-wrap:break-word"><div>I imagine physical layout like this is not uncommon in Swift code.  This does not necessarily mean you want these extensions to see implementation details of each other.  By adding a ‘scope’ access modifier we are able to properly hide these implementation details regardless of physical layout.  </div></div></blockquote><br></div><div>As mentioned above, what if you only want to make them available to <i>some</i> of the extensions?</div><div><br></div><div>-David</div><div><br></div></div></div></div></div></blockquote></div><br></div></div></div></div>
<img src="https://u2002410.ct.sendgrid.net/wf/open?upn=6ZGE61OxINd5lLe2xYh9Ku-2BXbixWNr2nvfzp2IB1sZitftEN7SC9V1Wn6I-2BUCwqqghOWKYDumfxJfxE3gATt3pKi48EMhDV3fb-2Fsgb4R0qdfHTIKqi2vJW-2Fcttv49FUbHVS4Z6GbdEelSkQwkF3itK1zxbVy66YPxzf2z81HeLCbpw1Mw6bpTL0rhabmJizZjKZb9jF9tH8DOkIM6QcZlw-3D-3D" alt="" width="1" height="1" border="0" style="min-height:1px!important;width:1px!important;border-width:0!important;margin-top:0!important;margin-bottom:0!important;margin-right:0!important;margin-left:0!important;padding-top:0!important;padding-bottom:0!important;padding-right:0!important;padding-left:0!important">
</div>
<br>_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">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>