access control proposal

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”.

I was referring specifically to extensions that *do not* require private access to the type, but rather work exclusively with its internal or public members. Extensions such as this are not uncommon and may have implementation details of their own which do not need to be visible outside the extension.

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.

We are not discussing protected access here. I don’t like it and would not support adding it to Swift.

Matthew

As soon as we say that we need to allow access for performance, scope or
local is not applicable. For that, private is perfect. But it should be a
rare exception and an alarm for anyone reading the code that the API
invariant could be broken by something else in the file. Most APIs don't
need this and should completely hide their implementation details. Local is
for that case. Distinguishing these cases helps clarifying the intent for
whoever is reading the code. The most important part though is that the
compiler enforces that intent.

···

--
Ilya Belenkiy

On Mon, Dec 14, 2015 at 11:52 AM David Owens II <david@owensd.io> wrote:

Let’s take this it’s next logical conclusion: I have two types that need
to access each other’s members for some significant performance gain. Let’s
call these types A and B. Now, A also needs access to the inner members for
C for the same reason (but note that B does not). I currently have other
related types all in the same file, let’s say D and E.

Now, all members should be “local” to the types, but remember, A needs to
access B's and C's members and the other types do not. Also, I can’t simply
move the them to different files because they have non-overlapping “local”
usage requirements. So do I need to create a “local friend” modifier so
only particular types can access the inner details?

There’s a line somewhere where complexity becomes more burdensome. I’m not
sure if “local” is that line, but I absolutely do know that “local friend”
is across that line (because of course we’ll need private friend and
internal friend modifiers as well…).

I imagine physical layout like this is not uncommon in Swift code. This
does not necessarily mean you want these extensions to see implementation
details of each other. By adding a ‘scope’ access modifier we are able to
properly hide these implementation details regardless of physical layout.

As mentioned above, what if you only want to make them available to *some* of
the extensions?

-David

If something is not an implementation detail and should be shared, local
doesn't apply. This applies equally to types and extensions. Subclasses may
or may not need access to the internals of a class. If the class can share
those implementation details, they should not be local (really called
private in many other languages). But they can and should be hidden most of
the time -- it's just part of designing a good APIs that implementations
hide behind small, focused, and convenient interfaces. Local will help
enforce it.

···

--
Ilya Belenkiy

On Mon, Dec 14, 2015 at 12:17 PM David Owens II <david@owensd.io> wrote:

On Dec 14, 2015, at 8:58 AM, Matthew Johnson <matthew@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

Isn't declaring "scope" access for a type at file-level effectively the
same as "internal"?
All symbols I declare at top-level of a file have "internal" access by
default.

For me "public", "internal" and "private" ARE access *scopes* so adding
"scope" as an additional access scope is somehow confusing.

···

On Mon, Dec 14, 2015 at 5:58 PM, Matthew Johnson via swift-evolution < swift-evolution@swift.org> 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.

Matthew

On Dec 14, 2015, at 10:52 AM, David Owens II <david@owensd.io> wrote:

Let’s take this it’s next logical conclusion: I have two types that need
to access each other’s members for some significant performance gain. Let’s
call these types A and B. Now, A also needs access to the inner members for
C for the same reason (but note that B does not). I currently have other
related types all in the same file, let’s say D and E.

Now, all members should be “local” to the types, but remember, A needs to
access B's and C's members and the other types do not. Also, I can’t simply
move the them to different files because they have non-overlapping “local”
usage requirements. So do I need to create a “local friend” modifier so
only particular types can access the inner details?

There’s a line somewhere where complexity becomes more burdensome. I’m not
sure if “local” is that line, but I absolutely do know that “local friend”
is across that line (because of course we’ll need private friend and
internal friend modifiers as well…).

I imagine physical layout like this is not uncommon in Swift code. This
does not necessarily mean you want these extensions to see implementation
details of each other. By adding a ‘scope’ access modifier we are able to
properly hide these implementation details regardless of physical layout.

As mentioned above, what if you only want to make them available to *some* of
the extensions?

-David

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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@swift.org> wrote:

On Dec 14, 2015, at 8:58 AM, Matthew Johnson <matthew@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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@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@swift.org> wrote:

On Dec 14, 2015, at 8:58 AM, Matthew Johnson <matthew@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Yes, declaring it for a top level type in a file doesn't make sense. It's really for anything inside a scope that this scope is hiding. That's why I prefer to call it local. The name doesn't matter too much to me (as long as as it's reasonable). The important thing is that there is a way to completely hide implementation details inside s scope (a type or an extension) that does not force me to put every such scope into a separate file.

The name doesn’t matter much to me either. We discussed the reasons why ‘local’ is not a good name several days ago. At the time everyone involved in the discussion seemed to understand ‘scope’ but it may also be confusing to enough people that we should find something else. I will give this some further thought.

Matthew

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@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@anandabits.com <mailto:matthew@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@knaup.koeln <mailto:marc@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@swift.org <mailto:swift-evolution@swift.org>> wrote:

On Dec 14, 2015, at 8:58 AM, Matthew Johnson <matthew@anandabits.com <mailto:matthew@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@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

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@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@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@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@swift.org> wrote:

On Dec 14, 2015, at 8:58 AM, Matthew Johnson <matthew@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Yes, declaring it for a top level type in a file doesn't make sense. It's
really for anything inside a scope that this scope is hiding. That's why I
prefer to call it local. The name doesn't matter too much to me (as long as
as it's reasonable). The important thing is that there is a way to
completely hide implementation details inside s scope (a type or an
extension) that does not force me to put every such scope into a separate
file.

···

--
Ilya Belenkiy

On Mon, Dec 14, 2015 at 12:05 PM Marc Knaup <marc@knaup.koeln> wrote:

Isn't declaring "scope" access for a type at file-level effectively the
same as "internal"?
All symbols I declare at top-level of a file have "internal" access by
default.

For me "public", "internal" and "private" ARE access *scopes* so adding
"scope" as an additional access scope is somehow confusing.

On Mon, Dec 14, 2015 at 5:58 PM, Matthew Johnson via swift-evolution < > swift-evolution@swift.org> 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.

Matthew

On Dec 14, 2015, at 10:52 AM, David Owens II <david@owensd.io> wrote:

Let’s take this it’s next logical conclusion: I have two types that need
to access each other’s members for some significant performance gain. Let’s
call these types A and B. Now, A also needs access to the inner members for
C for the same reason (but note that B does not). I currently have other
related types all in the same file, let’s say D and E.

Now, all members should be “local” to the types, but remember, A needs to
access B's and C's members and the other types do not. Also, I can’t simply
move the them to different files because they have non-overlapping “local”
usage requirements. So do I need to create a “local friend” modifier so
only particular types can access the inner details?

There’s a line somewhere where complexity becomes more burdensome. I’m
not sure if “local” is that line, but I absolutely do know that “local
friend” is across that line (because of course we’ll need private friend
and internal friend modifiers as well…).

I imagine physical layout like this is not uncommon in Swift code. This
does not necessarily mean you want these extensions to see implementation
details of each other. By adding a ‘scope’ access modifier we are able to
properly hide these implementation details regardless of physical layout.

As mentioned above, what if you only want to make them available to
*some* of the extensions?

-David

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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@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@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@swift.org> wrote:

On Dec 14, 2015, at 8:58 AM, Matthew Johnson <matthew@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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@anandabits.com> wrote:

It was an exchange John McCall and I had on the 9th.

[swift-evolution] access control proposal

[swift-evolution] access control proposal

[swift-evolution] access control proposal

[swift-evolution] access control proposal

Matthew

On Dec 14, 2015, at 11:49 AM, Ilya Belenkiy <ilya.belenkiy@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@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@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@swift.org> wrote:

On Dec 14, 2015, at 8:58 AM, Matthew Johnson <matthew@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Even the Swift documentation refers uses the terms "scope" and "scoped" to
refer to the access *scope* a symbol has.
https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/AccessControl.html#//apple_ref/doc/uid/TP40014097-CH41-ID3

It's unlikely that an access modifier will ever be called like that since
it's just bogus and confusing.

···

On Mon, Dec 14, 2015 at 6:25 PM, Matthew Johnson <matthew@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@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@swift.org> wrote:

On Dec 14, 2015, at 8:58 AM, Matthew Johnson <matthew@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

That works too.

···

--
Ilya Belenkiy
On Mon, Dec 14, 2015 at 1:30 PM Matthew Johnson <matthew@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@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@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@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@swift.org> wrote:

On Dec 14, 2015, at 8:58 AM, Matthew Johnson <matthew@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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@anandabits.com> wrote:

It was an exchange John McCall and I had on the 9th.

[swift-evolution] access control proposal

[swift-evolution] access control proposal

[swift-evolution] access control proposal

[swift-evolution] access control proposal

Matthew

On Dec 14, 2015, at 11:49 AM, Ilya Belenkiy <ilya.belenkiy@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@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@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@swift.org> wrote:

On Dec 14, 2015, at 8:58 AM, Matthew Johnson <matthew@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

This is *not* correct. It only grants access to other members declared within the same body. Some examples may help clarify the concept:

struct S {
    // visible within the struct declaration only and *nowhere* else
    scoped let foo: String

    struct T {
        // still within the scope of S so foo is still visible here
        // buzz is only visible within the inner type, buzz is not visible to members of S
        scoped let buzz: String
    }
}

// in same file
extension S {
    // foo is not visible here
    // bar is visible only within the extension in which it is declared and *nowhere* else
    scoped fun bar() -> String
}

···

On Dec 14, 2015, at 11:58 AM, Marc Knaup <marc@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?

I do not like the idea of a "boundary" or "break private" at all.

I think a number of objections are due to not understanding what we're talking about properly. It has not been explained clearly and concisely in a formal proposal and this discussion has been going for a week or so.

Other objections have to do with confusion around or dislike of the keyword.

There are also some objections to the concept itself, but I believe anyone objecting to that will also object to any alternative proposals.

I think it's best to let the discussion die off until we have a clear and concise explanation in a draft of a proposal. Ideally we can find a keyword that doesn't have potential for confusion as well.

Matthew

···

Sent from my iPad

On Dec 14, 2015, at 12:16 PM, ilya <ilya.nikokoshev@gmail.com> wrote:

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@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@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@anandabits.com> wrote:
It was an exchange John McCall and I had on the 9th.

[swift-evolution] access control proposal
[swift-evolution] access control proposal
[swift-evolution] access control proposal
[swift-evolution] access control proposal

Matthew

On Dec 14, 2015, at 11:49 AM, Ilya Belenkiy <ilya.belenkiy@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@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@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@swift.org> wrote:

On Dec 14, 2015, at 8:58 AM, Matthew Johnson <matthew@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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@gmail.com> wrote:

That works too.

--
Ilya Belenkiy

On Mon, Dec 14, 2015 at 1:30 PM Matthew Johnson <matthew@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@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@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@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@swift.org> wrote:

On Dec 14, 2015, at 8:58 AM, Matthew Johnson <matthew@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

If only the name is a problem, I am sure that we can come up with a good
name. scoped and local are just 2 potentially good names (and the
documentation could be updated if it's decided to use scoped).

···

--
Ilya Belenkiy
On Mon, Dec 14, 2015 at 12:31 PM Marc Knaup <marc@knaup.koeln> wrote:

Even the Swift documentation refers uses the terms "scope" and "scoped" to
refer to the access *scope* a symbol has.

The Swift Programming Language: Redirect

It's unlikely that an access modifier will ever be called like that since
it's just bogus and confusing.

On Mon, Dec 14, 2015 at 6:25 PM, Matthew Johnson <matthew@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@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@swift.org> wrote:

On Dec 14, 2015, at 8:58 AM, Matthew Johnson <matthew@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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@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@anandabits.com> > wrote:

It was an exchange John McCall and I had on the 9th.

[swift-evolution] access control proposal

[swift-evolution] access control proposal

[swift-evolution] access control proposal

[swift-evolution] access control proposal

Matthew

On Dec 14, 2015, at 11:49 AM, Ilya Belenkiy <ilya.belenkiy@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@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@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@swift.org> wrote:

On Dec 14, 2015, at 8:58 AM, Matthew Johnson <matthew@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution