I am not arguing that internal shouldn’t be the default… just that we need something else to fill the void that is created by having it be the default. That could be submodules, it could be ‘hidden’, it could be something else…
I am saying we need to take a wider view and look at what is actually bothering people. Just renaming things won’t solve the underlying issue… We need to come up with a cohesive story around access modifiers. Thanks, Jon > On Feb 21, 2017, at 12:22 AM, David Hart <[email protected]> wrote: > > >> On 21 Feb 2017, at 08:36, Jonathan Hull <[email protected] >> <mailto:[email protected]>> 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 >>> <[email protected] <mailto:[email protected]>> 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 >>> [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
