<div style="white-space:pre-wrap">Yes, declaring it for a top level type in a file doesn't make sense. It's really for anything inside a scope that this scope is hiding. That's why I prefer to call it local. The name doesn't matter too much to me (as long as as it's reasonable). The important thing is that there is a way to completely hide implementation details inside s scope (a type or an extension) that does not force me to put every such scope into a separate file.<br><br>--<br>Ilya Belenkiy</div><br><div class="gmail_quote"><div dir="ltr">On Mon, Dec 14, 2015 at 12:05 PM Marc Knaup <marc@knaup.koeln> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Isn't declaring "scope" access for a type at file-level effectively the same as "internal"?<div>All symbols I declare at top-level of a file have "internal" access by default.</div><div><br></div><div>For me "public", "internal" and "private" ARE access <i>scopes</i> so adding "scope" as an additional access scope is somehow confusing.</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote"></div></div><div class="gmail_extra"><div class="gmail_quote">On Mon, Dec 14, 2015 at 5:58 PM, Matthew Johnson via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br></div></div><div class="gmail_extra"><div class="gmail_quote"><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><div><br><div><blockquote type="cite"><div>On Dec 14, 2015, at 10:52 AM, David Owens II <<a href="mailto:david@owensd.io" target="_blank">david@owensd.io</a>> 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's and C'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>
</div></blockquote></div></div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><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></blockquote></div></div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<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></div></blockquote></div>