> On 21 Feb 2017, at 08:36, Jonathan Hull <jh...@gbis.com> wrote: > > I believe the actual problem is with ‘internal’, and that our problems with > private are a symptom of that deeper issue. We need to fix the deeper > underlying issue. > > From this blog post (https://developer.apple.com/swift/blog/?id=11 > <https://developer.apple.com/swift/blog/?id=11>), it seems Internal was meant > to share parts of types which should be internal to the type, but need to be > shared with related types.
What gives you that impression? I’ve never had that impression. > The issue is that, because internal is the default, it doesn’t express > authorial intent about the internal-ness of a given member, and it feels too > open not to be accidentally used (especially inside an app, where it is > essentially the same as public). I don’t agree. It represents a sane default that makes it easy for single-module applications to share all types together, while hiding members which need to be with private, and at the same time being a sane default for a library which should only thoughtfully render types/members public. > What we need is a way for the author to express: "This is internal to the > type, don’t mess with it unnecessarily” while still allowing (opt-in?) access > when necessary. Swift 2’s private did a pretty good job of that, allowing > anything that was located together to see each other’s internal bits, but > because it only worked for one file it results in super long files. The idea > of location based sharing is a good one though and is simple to teach. > > I think that larger context needs to be examined when considering what to do > here. For example, perhaps the answer is replacing fileprivate a module > system (if it can be done without adding too much complexity). My ideal > solution would unify access modifiers back to a single concept (either file > or scope/type based, but not both). > > Thanks, > Jon > > >> On Feb 20, 2017, at 10:58 PM, David Hart via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >> Hello list, >> >> Matthew Johnson and I have been putting our proposals together towards a >> joint “let’s fix private access levels” proposal. As the community seems >> quite divided on the issue, we offer two solutions in our proposal to let >> the community debate and to let the core team make the final decision. >> >> I’d like to concentrate this round of feedback on the quality of the >> proposal, and not on the merits of Solution 1 or 2. thoughts? >> >> https://github.com/hartbit/swift-evolution/blob/fix-private-access-levels/proposals/XXXX-fix-private-access-levels.md >> >> <https://github.com/hartbit/swift-evolution/blob/fix-private-access-levels/proposals/XXXX-fix-private-access-levels.md> >> >> David. >> >> Fix Private Access Levels >> >> Proposal: SE-XXXX >> <https://github.com/hartbit/swift-evolution/blob/fix-private-access-levels/proposals> >> Authors: David Hart <http://github.com/hartbit>, Matthew Johnson >> <https://github.com/anandabits> >> Review Manager: TBD >> Status: TBD >> >> <https://github.com/hartbit/swift-evolution/tree/fix-private-access-levels#introduction>Introduction >> >> This proposal presents the problems the came with the the access level >> modifications in SE-0025 >> <https://github.com/apple/swift-evolution/blob/master/proposals/0025-scoped-access-level.md> >> and presents two community driven solutions to fix them. As a consensus >> will not easily emerge, this proposal will allow a last round of voting and >> let the core team decide. Once that is done, this proposal will be ammended >> to describe the chosen solution. >> >> >> <https://github.com/hartbit/swift-evolution/tree/fix-private-access-levels#motivation>Motivation >> >> Since the release of Swift 3, the access level change of SE-0025 was met >> with dissatisfaction by a substantial proportion of the general Swift >> community. Before offering solutions, lets discuss how and why it can be >> viewed as actiely harmful, the new requirement for syntax/API changes. >> >> >> <https://github.com/hartbit/swift-evolution/tree/fix-private-access-levels#criticisms-of-se-0025>Criticisms >> of SE-0025 >> >> There are two primary criticism that have been offered. >> >> The first is that private is a "soft default" access modifier for >> restricting access within a file. Scoped access is not a good behavior for a >> "soft default" because it is extremely common to use several extensions >> within a file. A "soft default" (and therefore private) should work well >> with this idiom. It is fair to say that changing the behavior of private >> such that it does not work well with extensions meets the criteria of >> actively harmful in the sense that it subtly encourages overuse of scoped >> access control and discourages the more reasonable default by giving it the >> awkward name fileprivate. >> >> The second is that Swift's system of access control is too complex. Many >> people feel like restricting access control to scopes less than a file is of >> dubious value and therefore wish to simplify Swift's access control story by >> removing scoped access. However, there are many others who like the ability >> to have the compiler verify tighter access levels and believe it helps make >> it easier to reason about code which is protecting invariants. >> >> >> <https://github.com/hartbit/swift-evolution/tree/fix-private-access-levels#detailed-design>Detailed >> design >> >> Both authors agree that the private keyword should be reverted back to its >> Swift 2 file-based meaning, resolving the first criticism. But the authors >> disagree on what should be done about the scoped access level and the >> following solutions represent the two main opinions in the community: >> >> >> <https://github.com/hartbit/swift-evolution/tree/fix-private-access-levels#solution-1-remove-the-scoped-access-level>Solution >> 1: Remove the scoped access level >> >> Compared to a file-based access level, the scoped-based access level adds >> meaningful information by hiding implementation details which do not concern >> other types or extensions in the same file. But is that distinction between >> private and fileprivate actively used by the larger community of Swift >> developers? And if it were used pervasively, would it be worth the cognitive >> load and complexity of keeping two very similar access levels in the >> language? This solution argues that answer to both questions is no and that >> the scoped access level should be removed to resolve the complexity >> criticism. >> >> This solution has the added advantage of leaving the most design >> breathing-room for future discussions about access levels in regards to >> submodules. >> >> >> <https://github.com/hartbit/swift-evolution/tree/fix-private-access-levels#solution-2-rename-the-scoped-access-level-to-scoped>Solution >> 2: Rename the scoped access level to scoped >> >> It is difficult to make the case that a feature which a nontrivial number of >> Swift users find valuable and which is easy for teams to avoid is actively >> harmful. It seems like something that falls more into the category of a >> debate over style (which could be addressed by a linter). Should we remove a >> feature whose utility is a question of style, but is not actively harmful in >> the sense of causing programmer error? The second solution argues against it >> and proposes renaming it to scoped. >> >> The scoped keyword is a good choice not only because the community has been >> calling this feature “scoped access control” all along, but also because the >> principle underlying all of Swift’s access levels is the idea of a scope. >> >> >> <https://github.com/hartbit/swift-evolution/tree/fix-private-access-levels#source-compatibility>Source >> compatibility >> >> In Swift 3 compatibility mode, the compiler will continue to treat private >> and fileprivate as was previously the case. >> >> In Swift 4 mode, the compiler will deprecate the fileprivate keyword and >> revert the semantics of the private access level to be file based. The >> migrator will rename all uses of fileprivate to private. In solution 2, the >> migrator will also rename all uses of private to scoped. >> >> With solution 1 (and with solution 2 if the migrator is not run), cases >> where a type had private declarations with the same signature in different >> scopes will produce a compiler error. For example, the following piece of >> code compiles in Swift 3 compatibilty mode but generates a Invalid >> redeclaration of 'foo()' error in Swift 4 mode. >> >> struct Foo { >> private func bar() {} >> } >> >> extension Foo { >> private func bar() {} >> } >> >> <https://github.com/hartbit/swift-evolution/tree/fix-private-access-levels#alternatives-considered>Alternatives >> Considered >> >> Deprecate fileprivate and modify the semantics of private to include >> same-type extension scopes in the same file. >> Deprecate fileprivate and modify the semantics of private to include >> same-type extension scopes in the same module. >> The alternatives are potentially interesting but completely remove the file >> access level while making the new privateaccess level more complicated to >> explain and understand. >> _______________________________________________ >> 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
