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