[swift-evolution] access control proposal

[Ilya Belenkiy]

I see. I read those emails, and I think I replied as well. My take on it is
that it is no more confusing than using private to not mean the access
level that we are discussing right now. If private is already taken and we
cannot rename things, I'd say that local is my next choice. I also like
scoped.

--
Ilya Belenkiy
On Mon, Dec 14, 2015 at 12:53 PM Matthew Johnson <matthew at anandabits.com>
wrote:

> It was an exchange John McCall and I had on the 9th.
>
>
> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/001296.html
>
> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/001300.html
>
> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/001304.html
>
> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/001305.html
>
>
> Matthew
>
> On Dec 14, 2015, at 11:49 AM, Ilya Belenkiy <ilya.belenkiy at gmail.com>
> wrote:
>
> I missed it. I am not attached to it, but I wish I could see where it
> happened. Can you point me to the emails?
>
> --
> Ilya Belenkiy
>
> On Mon, Dec 14, 2015 at 12: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/38a32efb/attachment.html>