> On 21 Feb 2017, at 12:44, Andrey Fidrya <a...@zabiyaka.com> wrote:
>
> >Alternatives Considered:
> >2. Deprecate fileprivate and modify the semantics of private to include
> >same-type extension scopes in the same module.
>
> Imho, this is a better alternative.
>
> I rarely implement class extensions in the same file. Most often they have
> their own files, like
> MyClass+Search.swift
> MyClass+SomethingElse.swift
>
> Even in cases where implementing them in the same file makes sense, I'm not
> using current fileprivate modifier on variables because if I later have to
> implement an extension in a different file, I'll have to remove all these
> modifiers.
>
>
> Also, I don't think internal is a good default choice... Even if private is
> changed back to mean "file private" or "class private", it will add a lot of
> visual noise... For proper access limitation, basically everything has to be
> marked "private". Compare:
>
> class C {
> var a = 1
> var b = 2
> func f() { }
> }
>
> to:
>
> class C {
> private var a = 1
> private var b = 2
> private func f() { etc }
> }
>
>
> Also, in classes inheritance is denied by default, but variables have more
> open 'internal' access level by default.
> It looks like an inconcistency to me. Users have to explicitly allow
> inheritance, but disallow access to variables.
>
>
> +1 to the arguments about not mixing concepts (file or scope/type based).
> Personally I'd prefer scope/type only.
> Also, fileprivate access doesn't play well with playgrounds and makes
> rearranging code harder.
>
>
> If redesigning this from scratch, I'm thinking of this design:
> 1. scoped (works like the current private)
> 2. private (to the class + it's extensions inside the module) - and making it
> the default
> 3. internal (to the module). Should be set only on variables where it's
> really needed (will be rarely used).
In the previous very long thread, many people acknowledged that type + its
extensions private was too complex for its own good. Do you have arguments
against that? And even if it was proposed, I think many people would be very
opposed to keeping scoped in that case. There would be too little difference
between the two to be worth it.
> One more argument for adding "scoped" access level:
> if it will be allowed to declare variables in extensions of the same module
> in the future, having "scoped" would be very convenient as there can be
> multiple extensions in the same file.
>
>
> Regards,
> Andrey
>
>
>
>> On 21 Feb 2017, at 09:58, 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
