> On 22 Feb 2017, at 16:33, Matthew Johnson <matt...@anandabits.com> wrote: > > >> On Feb 22, 2017, at 12:32 AM, David Hart <da...@hartbit.com >> <mailto:da...@hartbit.com>> wrote: >> >> >>> On 21 Feb 2017, at 23:41, Xiaodi Wu <xiaodi...@gmail.com >>> <mailto:xiaodi...@gmail.com>> wrote: >>> >>> Well-written as-is. >>> >>> Overall, my feedback is that solution 2 should not be on the table (though >>> there are people who clamor for it), and not because I don't agree with it. >>> However, simply as a matter of following an appropriate process, solution 2 >>> was originally proposed in SE-0025, fully considered, and modified by the >>> core team to the current design. One can disagree whether `scoped` is more >>> appropriate than `private` as a name for that access modifier, and one is >>> likely to say that `private` looks nicer than `fileprivate`, but that's >>> neither here nor there. The appropriateness or niceness of these terms is >>> unchanged from last year. Re-submitting SE-0025 cannot be the solution for >>> fixing SE-0025. >> >> I agree with you, as you know that I support Solution 1. But I was hoping to >> reduce the amount of community flamewar by giving each alternative a level >> chance and letting the core team decide. But you make a good point about the >> fact that it was the state SE-0025 was it before it was modified by the core >> team. And I’m starting to have doubts. What do you think Matthew? > > I’d like to let the submodule discussion simmer a little bit more before > commenting on this question. The outcome of that could have a significant > impact on what I think we should do about SE-0025. When we put this proposal > together I was assuming submodules were going to be out of scope for Swift 4, > but it looks like at least the discussion is not. Even if we don’t end up > with a formal review of a submodule proposal the discussion might lead to a > better idea of what kind of proposal might have a chance to be accepted in > the future (by gauging community sentiment in the discussions, etc).
Ok, lets give it a little while. >> >>> On Tue, Feb 21, 2017 at 12:58 AM, David Hart <da...@hartbit.com >>> <mailto:da...@hartbit.com>> 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 https://lists.swift.org/mailman/listinfo/swift-evolution
