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.
On Tue, Feb 21, 2017 at 12:58 AM, David Hart <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 > > 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 > > 1. Deprecate fileprivate and modify the semantics of private to > include same-type extension scopes in the same file. > 2. 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
