[swift-evolution] access control proposal

[ilya]

How about

private enclosed {
private func foo()
}

func bar() {
// no access to foo()
}

And there will be no need for new keywords.

On Mon, Dec 14, 2015 at 22:28 Matthew Johnson via swift-evolution <
swift-evolution at swift.org> wrote:

> I thought of another I am not at all sure of, but in the spirit of open
> brainstorming here it is: 'enclosed'.
>
> Sent from my iPhone
>
> On Dec 14, 2015, at 12:42 PM, Ilya Belenkiy <ilya.belenkiy at gmail.com>
> wrote:
>
> 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
>>>>
>>>>
>>> _______________________________________________
> 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/8b4bf6a6/attachment.html>