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

Fri Apr 14 17:44:18 CDT 2017

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 at 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 at swift.org <mailto:swift-evolution at 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 at swift.org <mailto:swift-evolution at 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 at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> Pull request: https://github.com/apple/swift-evolution/pull/681 <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 <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170414/75966f50/attachment.html>