[swift-evolution] [Draft] Fix Private Access Levels

[Xiaodi Wu]

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 <david at 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170221/f3e0c18e/attachment-0001.html>