[swift-evolution] access control proposal

Ilya Belenkiy ilya.belenkiy at gmail.com
Mon Dec 14 12:42:54 CST 2015


That works too.

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

> I have been brainstorming other ideas for naming the keyword.  One that
> comes to mind is 'lexical'.  Not sure I like it but thought it was worth
> mentioning.
>
> Matthew
>
> Sent from my iPad
>
> 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/f1747c1f/attachment.html>


More information about the swift-evolution mailing list