Yet Another Access Control Pitch: Flexible Scoping

Evolution Discussion
1

Pull request: Flexible Access Control Scoping by erica · Pull Request #681 · apple/swift-evolution · GitHub

Under the assumption that SE-0169 is adopted, Jeffrey B and I have been brainstorming about what a follow-on might look like. We want to address concerns that remain post-0169. Although this proposal is primarily additive, we feel it might just squeak in under Swift 4's gate as it targets potentially harmful language issues.

We appreciate your feedback about the substance of the proposal. At this time, we're not looking for bikeshedding on design details. We will welcome that once the question of whether the proposal is sufficiently substantive is settled.

Given the extremely limited timeline and the high volume of list traffic, we're looking for specific concerns (or benefits) you see in this pitch instead of a flurry of "+1" and "-1" responses . Our primary question regards whether this is a suitable approach (it is strongly influenced by SE-0077) and flexible enough to cover at least some outstanding concerns raised in list threads over the past weeks.

Thank you in advance for your feedback,

-- Erica

2

Hi Erica,

I think this proposal needs to address how allowing arbitrary identifiers to become declaration modifiers would work during parsing. Custom accessgroups may not be in the same file - or even module - as the code they effect, meaning that

foo
bar
func myFunction() {}

cannot be parsed into anything reasonable until we’ve first found all of the visible accessgroup declarations. It’s even worse when we do syntax-only parsing like we use for some IDE stuff (e.g. syntax colouring, code-folding). In that case we do not import any modules (not even the stdlib), and we are only looking at one file, not the full set of files in the module.

Ben

···

On Apr 14, 2017, at 1:58 PM, Erica Sadun via swift-evolution <swift-evolution@swift.org> wrote:

Pull request: Flexible Access Control Scoping by erica · Pull Request #681 · apple/swift-evolution · GitHub

Under the assumption that SE-0169 is adopted, Jeffrey B and I have been brainstorming about what a follow-on might look like. We want to address concerns that remain post-0169. Although this proposal is primarily additive, we feel it might just squeak in under Swift 4's gate as it targets potentially harmful language issues.

We appreciate your feedback about the substance of the proposal. At this time, we're not looking for bikeshedding on design details. We will welcome that once the question of whether the proposal is sufficiently substantive is settled.

Given the extremely limited timeline and the high volume of list traffic, we're looking for specific concerns (or benefits) you see in this pitch instead of a flurry of "+1" and "-1" responses . Our primary question regards whether this is a suitable approach (it is strongly influenced by SE-0077) and flexible enough to cover at least some outstanding concerns raised in list threads over the past weeks.

Thank you in advance for your feedback,

-- Erica

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

3

I hate to be negative, since you've clearly put a lot of great thought into
this. But ultimately, I feel that this is *significantly* more complicated
than the problem of access control needs to be in Swift. I'm struggling to
think of another programming language that supports this fine-grained level
of detail.

The ability to create custom groups sounds like something that a very small
minority of Swift writers would take advantage of. Meanwhile, it sounds
like it would have the potential to greatly increase the learning curve of
someone coming into a new code base, because now they have to potentially
learn a whole new set of bespoke custom access modifiers that the authors
decided to create.

I can only imagine that this would create a number of "dialects" of Swift,
which the core team strongly wants to avoid (and which we should want to
avoid as well). How would these access groups be namespaced? Are they
restricted to only being usable within their module? (Meaning that they
would effectively be erased when referencing a type/member with such groups
outside that module?) If not, how do we guarantee that access groups are
unique across code bases importing them from multiple modules? Regardless,
this would allow two different Swift authors to create new custom access
groups with the same name but completely different semantics.

The biggest problem, though, is that you can no longer look at a
type/member in relative isolation and see where it's accessible from.
"public", "internal", and so forth all have well-defined simple meanings.
This change would mean that any time I look at a type/member with a custom
access group, I have to go fishing for the group's declaration in order to
understand who does and doesn't have access to it.

IMO, programmers simply do not need to finely tune and audit the visibility
of their code to this level of detail. For public API boundaries, you
should absolutely be able to control things. But once you're within a
module or within a file—code that 99% of the time you as a developer or
development team have complete control over—the value of being able to
protect yourself from yourself or other teammates drops *significantly*. I
argued this about scoped private as well, but the core team felt that it
had legitimate enough use by a large enough number of people. On the other
hand, I can't imagine that this would hold its weight in terms of
value-added vs. implementation complexity and difficulty it would add to
making the language readable and learnable.

···

On Fri, Apr 14, 2017 at 2:01 PM Erica Sadun via swift-evolution < swift-evolution@swift.org> wrote:

Pull request: Flexible Access Control Scoping by erica · Pull Request #681 · apple/swift-evolution · GitHub

Under the assumption that SE-0169 is adopted, Jeffrey B and I have been
brainstorming about what a follow-on might look like. We want to address
concerns that remain post-0169. Although this proposal is primarily
additive, we feel it might just squeak in under Swift 4's gate as it
targets potentially harmful language issues.

We appreciate your feedback about the substance of the proposal. At this
time, we're not looking for bikeshedding on design details. We will welcome
that once the question of whether the proposal is sufficiently substantive
is settled.

Given the extremely limited timeline and the high volume of list traffic,
we're looking for specific concerns (or benefits) you see in this pitch
instead of a flurry of "+1" and "-1" responses . Our primary question
regards whether this is a suitable approach (it is strongly influenced by
SE-0077) and flexible enough to cover at least some outstanding concerns
raised in list threads over the past weeks.

Thank you in advance for your feedback,

-- Erica

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

4

Not to spoil the party, but IMO it's *very* unlikely that we'll take up
(yet) another proposal for access control changes in Swift 4.

just-keeping-it-real-ly y'rs,

···

on Fri Apr 14 2017, Erica Sadun <swift-evolution@swift.org> wrote:

Pull request: Flexible Access Control Scoping by erica · Pull Request #681 · apple/swift-evolution · GitHub
<https://github.com/apple/swift-evolution/pull/681&gt;

Under the assumption that SE-0169 is adopted, Jeffrey B and I have
been brainstorming about what a follow-on might look like. We want to
address concerns that remain post-0169. Although this proposal is
primarily additive, we feel it might just squeak in under Swift 4's
gate as it targets potentially harmful language issues.

--
-Dave

5

I have to say that — while the concerns of the others are certainly valid, especially with regards to namespacing — I do like this idea, especially how it unifies access control of lexical scopes with that of types and friends.

-Thorsten

···

Am 14.04.2017 um 22:58 schrieb Erica Sadun via swift-evolution <swift-evolution@swift.org>:

Pull request: Flexible Access Control Scoping by erica · Pull Request #681 · apple/swift-evolution · GitHub

Under the assumption that SE-0169 is adopted, Jeffrey B and I have been brainstorming about what a follow-on might look like. We want to address concerns that remain post-0169. Although this proposal is primarily additive, we feel it might just squeak in under Swift 4's gate as it targets potentially harmful language issues.

We appreciate your feedback about the substance of the proposal. At this time, we're not looking for bikeshedding on design details. We will welcome that once the question of whether the proposal is sufficiently substantive is settled.

Given the extremely limited timeline and the high volume of list traffic, we're looking for specific concerns (or benefits) you see in this pitch instead of a flurry of "+1" and "-1" responses . Our primary question regards whether this is a suitable approach (it is strongly influenced by SE-0077) and flexible enough to cover at least some outstanding concerns raised in list threads over the past weeks.

Thank you in advance for your feedback,

-- Erica

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

6

Afraid I have to agree - this proposal obviously had a lot of thought put into it, but my opinion is that this level of complexity disguises the purpose of access control.

The goal of access control (again IMHO) should be to support reduced coupling and encapsulation. The goal is to both increase the ability to work within a codebase without full knowledge of all of its code, and to allow evolution of an implementation while knowing what API surface must remain stable to avoid breaking dependent code.

So each access level needs to convey basically three things:
- What am I supposed to understand before I start working on this code (e.g. private = need to understand the workings of the type)
- What is the impact if I change this code (e.g. internal = this may break code within the current module, but shouldn’t affect the public ABI of the model)
- Is this considered an extension point for third parties to alter the behavior of my type

I don’t think custom access levels help better convey what a developer should know and what the impact of a change is.

-DW

···

On Apr 14, 2017, at 3:20 PM, Tony Allevato via swift-evolution <swift-evolution@swift.org> wrote:

I hate to be negative, since you've clearly put a lot of great thought into this. But ultimately, I feel that this is *significantly* more complicated than the problem of access control needs to be in Swift. I'm struggling to think of another programming language that supports this fine-grained level of detail.

The ability to create custom groups sounds like something that a very small minority of Swift writers would take advantage of. Meanwhile, it sounds like it would have the potential to greatly increase the learning curve of someone coming into a new code base, because now they have to potentially learn a whole new set of bespoke custom access modifiers that the authors decided to create.

I can only imagine that this would create a number of "dialects" of Swift, which the core team strongly wants to avoid (and which we should want to avoid as well). How would these access groups be namespaced? Are they restricted to only being usable within their module? (Meaning that they would effectively be erased when referencing a type/member with such groups outside that module?) If not, how do we guarantee that access groups are unique across code bases importing them from multiple modules? Regardless, this would allow two different Swift authors to create new custom access groups with the same name but completely different semantics.

The biggest problem, though, is that you can no longer look at a type/member in relative isolation and see where it's accessible from. "public", "internal", and so forth all have well-defined simple meanings. This change would mean that any time I look at a type/member with a custom access group, I have to go fishing for the group's declaration in order to understand who does and doesn't have access to it.

IMO, programmers simply do not need to finely tune and audit the visibility of their code to this level of detail. For public API boundaries, you should absolutely be able to control things. But once you're within a module or within a file—code that 99% of the time you as a developer or development team have complete control over—the value of being able to protect yourself from yourself or other teammates drops *significantly*. I argued this about scoped private as well, but the core team felt that it had legitimate enough use by a large enough number of people. On the other hand, I can't imagine that this would hold its weight in terms of value-added vs. implementation complexity and difficulty it would add to making the language readable and learnable.

On Fri, Apr 14, 2017 at 2:01 PM Erica Sadun via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
Pull request: Flexible Access Control Scoping by erica · Pull Request #681 · apple/swift-evolution · GitHub

Under the assumption that SE-0169 is adopted, Jeffrey B and I have been brainstorming about what a follow-on might look like. We want to address concerns that remain post-0169. Although this proposal is primarily additive, we feel it might just squeak in under Swift 4's gate as it targets potentially harmful language issues.

We appreciate your feedback about the substance of the proposal. At this time, we're not looking for bikeshedding on design details. We will welcome that once the question of whether the proposal is sufficiently substantive is settled.

Given the extremely limited timeline and the high volume of list traffic, we're looking for specific concerns (or benefits) you see in this pitch instead of a flurry of "+1" and "-1" responses . Our primary question regards whether this is a suitable approach (it is strongly influenced by SE-0077) and flexible enough to cover at least some outstanding concerns raised in list threads over the past weeks.

Thank you in advance for your feedback,

-- Erica

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto: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

7

Agree with all of the above.

This document was an important one for someone to write. It represents a
complete design that no doubt is what some people aim for when they propose
incremental changes that add just one more access modifier, and one more,
and one more.

What is clear is that a good chunk of the community (in discussions about
the rollback of SE-0025) and the core team (and I do believe they have
explicitly talked about a design like this, though only in passing),
believe the motivations outlined here to be explicitly *anti*-goals for the
language. Only with the existence of this document can we have discuss this
in a concrete way.

···

On Fri, Apr 14, 2017 at 16:51 David Waite via swift-evolution < swift-evolution@swift.org> wrote:

Afraid I have to agree - this proposal obviously had a lot of thought put
into it, but my opinion is that this level of complexity disguises the
purpose of access control.

The goal of access control (again IMHO) should be to support reduced
coupling and encapsulation. The goal is to both increase the ability to
work within a codebase without full knowledge of all of its code, and to
allow evolution of an implementation while knowing what API surface must
remain stable to avoid breaking dependent code.

So each access level needs to convey basically three things:
- What am I supposed to understand before I start working on this code
(e.g. private = need to understand the workings of the type)
- What is the impact if I change this code (e.g. internal = this may break
code within the current module, but shouldn’t affect the public ABI of the
model)
- Is this considered an extension point for third parties to alter the
behavior of my type

I don’t think custom access levels help better convey what a developer
should know and what the impact of a change is.

-DW

On Apr 14, 2017, at 3:20 PM, Tony Allevato via swift-evolution < > swift-evolution@swift.org> wrote:

I hate to be negative, since you've clearly put a lot of great thought
into this. But ultimately, I feel that this is *significantly* more
complicated than the problem of access control needs to be in Swift. I'm
struggling to think of another programming language that supports this
fine-grained level of detail.

The ability to create custom groups sounds like something that a very
small minority of Swift writers would take advantage of. Meanwhile, it
sounds like it would have the potential to greatly increase the learning
curve of someone coming into a new code base, because now they have to
potentially learn a whole new set of bespoke custom access modifiers that
the authors decided to create.

I can only imagine that this would create a number of "dialects" of Swift,
which the core team strongly wants to avoid (and which we should want to
avoid as well). How would these access groups be namespaced? Are they
restricted to only being usable within their module? (Meaning that they
would effectively be erased when referencing a type/member with such groups
outside that module?) If not, how do we guarantee that access groups are
unique across code bases importing them from multiple modules? Regardless,
this would allow two different Swift authors to create new custom access
groups with the same name but completely different semantics.

The biggest problem, though, is that you can no longer look at a
type/member in relative isolation and see where it's accessible from.
"public", "internal", and so forth all have well-defined simple meanings.
This change would mean that any time I look at a type/member with a custom
access group, I have to go fishing for the group's declaration in order to
understand who does and doesn't have access to it.

IMO, programmers simply do not need to finely tune and audit the
visibility of their code to this level of detail. For public API
boundaries, you should absolutely be able to control things. But once
you're within a module or within a file—code that 99% of the time you as a
developer or development team have complete control over—the value of being
able to protect yourself from yourself or other teammates drops
*significantly*. I argued this about scoped private as well, but the core
team felt that it had legitimate enough use by a large enough number of
people. On the other hand, I can't imagine that this would hold its weight
in terms of value-added vs. implementation complexity and difficulty it
would add to making the language readable and learnable.

On Fri, Apr 14, 2017 at 2:01 PM Erica Sadun via swift-evolution < > swift-evolution@swift.org> wrote:

Pull request: Flexible Access Control Scoping by erica · Pull Request #681 · apple/swift-evolution · GitHub

Under the assumption that SE-0169 is adopted, Jeffrey B and I have been
brainstorming about what a follow-on might look like. We want to address
concerns that remain post-0169. Although this proposal is primarily
additive, we feel it might just squeak in under Swift 4's gate as it
targets potentially harmful language issues.

We appreciate your feedback about the substance of the proposal. At this
time, we're not looking for bikeshedding on design details. We will welcome
that once the question of whether the proposal is sufficiently substantive
is settled.

Given the extremely limited timeline and the high volume of list traffic,
we're looking for specific concerns (or benefits) you see in this pitch
instead of a flurry of "+1" and "-1" responses . Our primary question
regards whether this is a suitable approach (it is strongly influenced by
SE-0077) and flexible enough to cover at least some outstanding concerns
raised in list threads over the past weeks.

Thank you in advance for your feedback,

-- Erica

_______________________________________________
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

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

8

Tony resumed very well my thought on this proposal. I'd like to add that even with all its complexity, it does not solve any of the issues introduced with SE-0025 and that the recent proposals have tried to fix. At the heart, SE-0159 and SE-0169 try to bring back a good safe-default private modifier. This proposal does not do that and a custom access level can never be a "default".

···

On 14 Apr 2017, at 23:20, Tony Allevato via swift-evolution <swift-evolution@swift.org> wrote:

I hate to be negative, since you've clearly put a lot of great thought into this. But ultimately, I feel that this is *significantly* more complicated than the problem of access control needs to be in Swift. I'm struggling to think of another programming language that supports this fine-grained level of detail.

The ability to create custom groups sounds like something that a very small minority of Swift writers would take advantage of. Meanwhile, it sounds like it would have the potential to greatly increase the learning curve of someone coming into a new code base, because now they have to potentially learn a whole new set of bespoke custom access modifiers that the authors decided to create.

I can only imagine that this would create a number of "dialects" of Swift, which the core team strongly wants to avoid (and which we should want to avoid as well). How would these access groups be namespaced? Are they restricted to only being usable within their module? (Meaning that they would effectively be erased when referencing a type/member with such groups outside that module?) If not, how do we guarantee that access groups are unique across code bases importing them from multiple modules? Regardless, this would allow two different Swift authors to create new custom access groups with the same name but completely different semantics.

The biggest problem, though, is that you can no longer look at a type/member in relative isolation and see where it's accessible from. "public", "internal", and so forth all have well-defined simple meanings. This change would mean that any time I look at a type/member with a custom access group, I have to go fishing for the group's declaration in order to understand who does and doesn't have access to it.

IMO, programmers simply do not need to finely tune and audit the visibility of their code to this level of detail. For public API boundaries, you should absolutely be able to control things. But once you're within a module or within a file—code that 99% of the time you as a developer or development team have complete control over—the value of being able to protect yourself from yourself or other teammates drops *significantly*. I argued this about scoped private as well, but the core team felt that it had legitimate enough use by a large enough number of people. On the other hand, I can't imagine that this would hold its weight in terms of value-added vs. implementation complexity and difficulty it would add to making the language readable and learnable.

On Fri, Apr 14, 2017 at 2:01 PM Erica Sadun via swift-evolution <swift-evolution@swift.org> wrote:
Pull request: Flexible Access Control Scoping by erica · Pull Request #681 · apple/swift-evolution · GitHub

Under the assumption that SE-0169 is adopted, Jeffrey B and I have been brainstorming about what a follow-on might look like. We want to address concerns that remain post-0169. Although this proposal is primarily additive, we feel it might just squeak in under Swift 4's gate as it targets potentially harmful language issues.

We appreciate your feedback about the substance of the proposal. At this time, we're not looking for bikeshedding on design details. We will welcome that once the question of whether the proposal is sufficiently substantive is settled.

Given the extremely limited timeline and the high volume of list traffic, we're looking for specific concerns (or benefits) you see in this pitch instead of a flurry of "+1" and "-1" responses . Our primary question regards whether this is a suitable approach (it is strongly influenced by SE-0077) and flexible enough to cover at least some outstanding concerns raised in list threads over the past weeks.

Thank you in advance for your feedback,

-- Erica

_______________________________________________
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

9

Like SE-0077's precedencegroup, this proposal is meant to mostly be invisible to end-users. Most Swift users will never know anything changed from S3/SE-0169 but it would support powerful use-cases for people who do serious coding.

-- E

···

On Apr 14, 2017, at 4:02 PM, Xiaodi Wu via swift-evolution <swift-evolution@swift.org> wrote:

Agree with all of the above.

This document was an important one for someone to write. It represents a complete design that no doubt is what some people aim for when they propose incremental changes that add just one more access modifier, and one more, and one more.

What is clear is that a good chunk of the community (in discussions about the rollback of SE-0025) and the core team (and I do believe they have explicitly talked about a design like this, though only in passing), believe the motivations outlined here to be explicitly *anti*-goals for the language. Only with the existence of this document can we have discuss this in a concrete way.
On Fri, Apr 14, 2017 at 16:51 David Waite via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
Afraid I have to agree - this proposal obviously had a lot of thought put into it, but my opinion is that this level of complexity disguises the purpose of access control.

The goal of access control (again IMHO) should be to support reduced coupling and encapsulation. The goal is to both increase the ability to work within a codebase without full knowledge of all of its code, and to allow evolution of an implementation while knowing what API surface must remain stable to avoid breaking dependent code.

So each access level needs to convey basically three things:
- What am I supposed to understand before I start working on this code (e.g. private = need to understand the workings of the type)
- What is the impact if I change this code (e.g. internal = this may break code within the current module, but shouldn’t affect the public ABI of the model)
- Is this considered an extension point for third parties to alter the behavior of my type

I don’t think custom access levels help better convey what a developer should know and what the impact of a change is.

-DW

On Apr 14, 2017, at 3:20 PM, Tony Allevato via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

I hate to be negative, since you've clearly put a lot of great thought into this. But ultimately, I feel that this is *significantly* more complicated than the problem of access control needs to be in Swift. I'm struggling to think of another programming language that supports this fine-grained level of detail.

The ability to create custom groups sounds like something that a very small minority of Swift writers would take advantage of. Meanwhile, it sounds like it would have the potential to greatly increase the learning curve of someone coming into a new code base, because now they have to potentially learn a whole new set of bespoke custom access modifiers that the authors decided to create.

I can only imagine that this would create a number of "dialects" of Swift, which the core team strongly wants to avoid (and which we should want to avoid as well). How would these access groups be namespaced? Are they restricted to only being usable within their module? (Meaning that they would effectively be erased when referencing a type/member with such groups outside that module?) If not, how do we guarantee that access groups are unique across code bases importing them from multiple modules? Regardless, this would allow two different Swift authors to create new custom access groups with the same name but completely different semantics.

The biggest problem, though, is that you can no longer look at a type/member in relative isolation and see where it's accessible from. "public", "internal", and so forth all have well-defined simple meanings. This change would mean that any time I look at a type/member with a custom access group, I have to go fishing for the group's declaration in order to understand who does and doesn't have access to it.

IMO, programmers simply do not need to finely tune and audit the visibility of their code to this level of detail. For public API boundaries, you should absolutely be able to control things. But once you're within a module or within a file—code that 99% of the time you as a developer or development team have complete control over—the value of being able to protect yourself from yourself or other teammates drops *significantly*. I argued this about scoped private as well, but the core team felt that it had legitimate enough use by a large enough number of people. On the other hand, I can't imagine that this would hold its weight in terms of value-added vs. implementation complexity and difficulty it would add to making the language readable and learnable.

On Fri, Apr 14, 2017 at 2:01 PM Erica Sadun via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
Pull request: Flexible Access Control Scoping by erica · Pull Request #681 · apple/swift-evolution · GitHub

Under the assumption that SE-0169 is adopted, Jeffrey B and I have been brainstorming about what a follow-on might look like. We want to address concerns that remain post-0169. Although this proposal is primarily additive, we feel it might just squeak in under Swift 4's gate as it targets potentially harmful language issues.

We appreciate your feedback about the substance of the proposal. At this time, we're not looking for bikeshedding on design details. We will welcome that once the question of whether the proposal is sufficiently substantive is settled.

Given the extremely limited timeline and the high volume of list traffic, we're looking for specific concerns (or benefits) you see in this pitch instead of a flurry of "+1" and "-1" responses . Our primary question regards whether this is a suitable approach (it is strongly influenced by SE-0077) and flexible enough to cover at least some outstanding concerns raised in list threads over the past weeks.

Thank you in advance for your feedback,

-- Erica

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

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto: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

10

Hi Erica,

Like SE-0077's precedencegroup, this proposal is meant to mostly be invisible to end-users. Most Swift users will never know anything changed from S3/SE-0169 but it would support powerful use-cases for people who do serious coding.

I really like this proposal (Flexible Scoping). My one suggestion would be to make it clearer that for the average user, they just keep using the pre-defined access control levels as you’ve mentioned above.

I’m a little tired of seeing flexible access control referred to as an anti-goal — everyone has different requirements from this language, and this is the first time I’ve seen something that would potentially cover everybody’s needs without needlessly restricting things to meet one group’s idea of best practice. I’d ask that members of the community please consider that their ideas and needs are not everybody’s ideas and needs when assessing potentially contentious proposals like this one.

Personally, I’ve found the conversations around access control on this mailing list draining to the point I’ve unsubscribed from the list a few times. This is the first time I've felt like someone might be on the right track to solving this issue in a future-proof manner, and not just whacking a band-aid on the actual underlying issues.

Regardless of the outcome of discussions around this, thank you for the work that Jeffrey and yourself have put into it.

I'll +1 the heck out of this proposal if it gets to review.

thanks,

Tony

···

On 15 Apr 2017, at 08:44, Erica Sadun via swift-evolution <swift-evolution@swift.org> wrote:

----------
Tony Arnold
+61 411 268 532
http://thecocoabots.com/

ABN: 14831833541

11

If we're to talk about ideas and needs, my favored access control design is
one that pares back to only two modifiers: public and internal. Either the
thing is public API, or it is not. Ditch everything else.

···

On Fri, Apr 14, 2017 at 19:42 Tony Arnold via swift-evolution < swift-evolution@swift.org> wrote:

Hi Erica,

> On 15 Apr 2017, at 08:44, Erica Sadun via swift-evolution < > swift-evolution@swift.org> wrote:
>
> Like SE-0077's precedencegroup, this proposal is meant to mostly be
invisible to end-users. Most Swift users will never know anything changed
from S3/SE-0169 but it would support powerful use-cases for people who do
serious coding.

I really like this proposal (Flexible Scoping). My one suggestion would be
to make it clearer that for the average user, they just keep using the
pre-defined access control levels as you’ve mentioned above.

I’m a little tired of seeing flexible access control referred to as an
anti-goal — everyone has different requirements from this language, and
this is the first time I’ve seen something that would potentially cover
everybody’s needs without needlessly restricting things to meet one group’s
idea of best practice. I’d ask that members of the community please
consider that their ideas and needs are not everybody’s ideas and needs
when assessing potentially contentious proposals like this one.

Personally, I’ve found the conversations around access control on this
mailing list draining to the point I’ve unsubscribed from the list a few
times. This is the first time I've felt like someone might be on the right
track to solving this issue in a future-proof manner, and not just whacking
a band-aid on the actual underlying issues.

Regardless of the outcome of discussions around this, thank you for the
work that Jeffrey and yourself have put into it.

I'll +1 the heck out of this proposal if it gets to review.

thanks,

Tony

----------
Tony Arnold
+61 411 268 532
http://thecocoabots.com/

ABN: 14831833541

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

12

While I appreciate the simplicity of such a statement, in reality it would be a step backward even from Objective-C and is not a practical design for anyone who works on a multi-person team. In Objective-C, members are selectively import’d, so everything is “private” unless it’s import’d. Since Swift takes the approach of implicit importation of the module, there’s no way to hide parts of functionality from other subsystems in your module without resorting to fragile and unsafe naming conventions (e.g.: “don’t use things that start with an underscore”). It would be a massive design mistake, for example, for every private method on every piece of code in UIKit to be exposed to every other client inside UIKit.

Dave

···

On Apr 14, 2017, at 9:31 PM, Xiaodi Wu via swift-evolution <swift-evolution@swift.org> wrote:

If we're to talk about ideas and needs, my favored access control design is one that pares back to only two modifiers: public and internal. Either the thing is public API, or it is not. Ditch everything else.
On Fri, Apr 14, 2017 at 19:42 Tony Arnold via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
Hi Erica,

> On 15 Apr 2017, at 08:44, Erica Sadun via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>
> Like SE-0077's precedencegroup, this proposal is meant to mostly be invisible to end-users. Most Swift users will never know anything changed from S3/SE-0169 but it would support powerful use-cases for people who do serious coding.

I really like this proposal (Flexible Scoping). My one suggestion would be to make it clearer that for the average user, they just keep using the pre-defined access control levels as you’ve mentioned above.

I’m a little tired of seeing flexible access control referred to as an anti-goal — everyone has different requirements from this language, and this is the first time I’ve seen something that would potentially cover everybody’s needs without needlessly restricting things to meet one group’s idea of best practice. I’d ask that members of the community please consider that their ideas and needs are not everybody’s ideas and needs when assessing potentially contentious proposals like this one.

Personally, I’ve found the conversations around access control on this mailing list draining to the point I’ve unsubscribed from the list a few times. This is the first time I've felt like someone might be on the right track to solving this issue in a future-proof manner, and not just whacking a band-aid on the actual underlying issues.

Regardless of the outcome of discussions around this, thank you for the work that Jeffrey and yourself have put into it.

I'll +1 the heck out of this proposal if it gets to review.

thanks,

Tony

----------
Tony Arnold
+61 411 268 532
http://thecocoabots.com/

ABN: 14831833541

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto: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

13

+1

I do still think that SE-0025 was a mistake, and that even more granular options will hurt the simplicity of the language way more than any gains that a small set of authors may gain. And to the detriment of other more useful features or improvements, since this will need to be implemented or at least maintained by the Core team.

···

El 15 abr 2017, a las 5:31, Xiaodi Wu via swift-evolution <swift-evolution@swift.org> escribió:

If we're to talk about ideas and needs, my favored access control design is one that pares back to only two modifiers: public and internal. Either the thing is public API, or it is not. Ditch everything else.

--
Víctor Pimentel

14

To be clear, I'm not suggesting that we should implement such a design (or
even discuss it in this thread); the core team has made very clear that it
won't happen. I'm simply stating that, insofar as there are some people who
wish for infinite granularity in access control--exemplified by this
proposal--there are others who believe that in a perfect world we would
distinguish only public API from non-public API. It goes without saying
that, in such a world, there would need to be facilities for selective
import.

(There are good reasons why one might need selective import facilities in
Swift as it is today, such as in the case of conflicting definitions of
operators, and there have been proposals which aim to solve this somewhat
orthogonal issue which are certainly worthy of consideration.)

···

On Sat, Apr 15, 2017 at 12:50 PM, Dave DeLong <delong@apple.com> wrote:

While I appreciate the simplicity of such a statement, in reality it would
be a step backward even from Objective-C and is not a practical design for
anyone who works on a multi-person team. In Objective-C, members are
selectively import’d, so *everything* is “private” unless it’s
import’d. Since Swift takes the approach of implicit importation of the
module, there’s no way to hide parts of functionality from other subsystems
in your module without resorting to fragile and unsafe naming conventions
(e.g.: “don’t use things that start with an underscore”). It would be a
massive design mistake, for example, for every private method on every
piece of code in UIKit to be exposed to every other client inside UIKit.