[swift-evolution] access control proposal

[ilya]

If the use case is about combining several private implementations into a
single file, I have a simpler suggestion: allow a "private boundary",
something like:



// MARK: some extension

extension Something {
private func foo() ...

}

break private

// MARK: another extension

extension Another {
private func bar() ...
// has no access to Something.foo
}



Or perhaps



private namespace {
extension Something ...
}


On Mon, Dec 14, 2015 at 21:05 Ilya Belenkiy via swift-evolution <
swift-evolution at swift.org> wrote:

> No, it grants the use only in the syntactic scope in which the symbol is
> defined. So if it's defined in an extension, only the other members inside
> those curly braces can access it.
>
> --
> Ilya Belenkiy
> On Mon, Dec 14, 2015 at 12:58 PM Marc Knaup <marc at knaup.koeln> wrote:
>
>> To sum up (what I understand) the new access modifier
>>
>>    - can be used only on type members (properties, methods,
>>    initializers, subscripts and nested types) - so not at file-level
>>    - grants access to that symbol to
>>       - the containing type
>>       - (nested types)?
>>       - extension in the same file
>>    - and does not grant access to
>>       - extensions declared in a different file
>>       - subclasses
>>       - other locations in the same file as the ones granted above
>>
>> Did I forget anything?
>>
>> On Mon, Dec 14, 2015 at 6: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
>>>>>
>>>>>
>>>>
>>>
>> _______________________________________________
> 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/214dfad6/attachment.html>