[swift-evolution] access control proposal

[Ilya Belenkiy]

If only the name is a problem, I am sure that we can come up with a good
name. scoped and local are just 2 potentially good names (and the
documentation could be updated if it's decided to use scoped).

--
Ilya Belenkiy
On Mon, Dec 14, 2015 at 12:31 PM Marc Knaup <marc at knaup.koeln> wrote:

> Even the Swift documentation refers uses the terms "scope" and "scoped" to
> refer to the access *scope* a symbol has.
>
> https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/AccessControl.html#//apple_ref/doc/uid/TP40014097-CH41-ID3
>
> It's unlikely that an access modifier will ever be called like that since
> it's just bogus and confusing.
>
> On Mon, Dec 14, 2015 at 6:25 PM, Matthew Johnson <matthew at anandabits.com>
> wrote:
>
>> The idea of calling this 'local' was abandoned a long time ago.  Any
>> proposal around this will be using 'scope' or 'scoped'.
>>
>> Sent from my iPad
>>
>> On Dec 14, 2015, at 11:22 AM, Marc Knaup <marc at knaup.koeln> wrote:
>>
>> What about "more private" or "really private"? :)
>> j/k
>>
>> I also thought about "local" but it's also not obvious what exactly that
>> means.
>> Maybe "my"?  my var xyz = …
>>
>> On Mon, Dec 14, 2015 at 6:17 PM, David Owens II via swift-evolution <
>> swift-evolution at swift.org> wrote:
>>
>>>
>>> On Dec 14, 2015, at 8:58 AM, Matthew Johnson <matthew at anandabits.com>
>>> 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.
>>>
>>>
>>> I think the simplest counter-example is your own example for extensions.
>>> Each extensions will need access to different internals of the the type
>>> it’s applied to. So when it comes time to add that extension, you’ll be
>>> forced to promote the access control from “local” to “private”.
>>>
>>> Another straight-forward one is a subclass. Since “local” would be
>>> “scope” based, a subclass would also knot have access to those members
>>> defined as local in the super class, so they’d have to be promoted to
>>> private and thus available to all code within the file.
>>>
>>> I think “local” fits this definition:
>>>
>>> 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.
>>>
>>>
>>> It’s not an obviously necessary modifier as it’s usage is extremely
>>> limited and requires to be bounced up a level is a lot of design
>>> considerations, such as extensions and subclasses. There are certainly
>>> times where “local” could be used, but my opinion is that it’s not worth
>>> complexity for the limited value that it actually brings to the table.
>>>
>>> -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/d05a14e0/attachment.html>