[swift-evolution] access control proposal

[Ilya Belenkiy]

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.

--
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>