[swift-evolution] access control proposal
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
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
> 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.
>> 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?
>> swift-evolution mailing list
>> swift-evolution at swift.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution