[swift-evolution] access control proposal
marc at knaup.koeln
Mon Dec 14 11:58:43 CST 2015
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
- 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>
> It was an exchange John McCall and I had on the 9th.
> On Dec 14, 2015, at 11:49 AM, Ilya Belenkiy <ilya.belenkiy at gmail.com>
> 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>
>> 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"? :)
>> I also thought about "local" but it's also not obvious what exactly that
>> 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>
>>> 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.
>>> swift-evolution mailing list
>>> swift-evolution at swift.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution