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 > <[email protected]> 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 >> <[email protected]> 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 >> [email protected] >> https://lists.swift.org/mailman/listinfo/swift-evolution > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
