[swift-evolution] access control proposal

Ilya Belenkiy ilya.belenkiy at gmail.com
Mon Dec 14 11:34:45 CST 2015

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

Ilya Belenkiy

On Mon, Dec 14, 2015 at 12:05 PM Marc Knaup <marc at knaup.koeln> wrote:

> Isn't declaring "scope" access for a type at file-level effectively the
> same as "internal"?
> All symbols I declare at top-level of a file have "internal" access by
> default.
> For me "public", "internal" and "private" ARE access *scopes* so adding
> "scope" as an additional access scope is somehow confusing.
> On Mon, Dec 14, 2015 at 5:58 PM, Matthew Johnson via swift-evolution <
> swift-evolution at swift.org> wrote:
>> 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.
>> 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.
>> Matthew
>> On Dec 14, 2015, at 10:52 AM, David Owens II <david at owensd.io> wrote:
>> 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.
>> 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?
>> 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…).
>> 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.
>> As mentioned above, what if you only want to make them available to
>> *some* of the extensions?
>> -David
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151214/e5161845/attachment.html>

More information about the swift-evolution mailing list