[swift-evolution] Yet Another Access Control Pitch: Flexible Scoping

[Tony Allevato]

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

> Pull request: https://github.com/apple/swift-evolution/pull/681
>
> 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 at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170414/910b55a3/attachment.html>