[swift-evolution] [Accepted] SE-0169: Improve Interaction Between `private` Declarations and Extensions

[Douglas Gregor]

Sent from my iPhone
> On Apr 18, 2017, at 6:58 AM, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
> 
> Does the acceptance of SE-0169 imply any change to rules for `private extension` members, or does the core team intend such members to continue defaulting to fileprivate visibility?

It does imply a change to "private extension" semantics: the members of such an extension would be "private", so they'd be visible to other extensions (and possibly the definition of) the extended type that occur in the same file. 

This makes the private/fileprivate distinction meaningful for extensions. I think also bans the use of "private" at global scope for non-nominal types or extensions thereof.  A clarifying update to the proposal is in order, so developers can better understand the semantics. 

Hey, and this gives me another reason why

  extension P where Self : Q { }

Might be a better spelling than

  extension P & Q { }

Despite the latter being more obvious :)

  - Doug


> 
> 
>> On Mon, Apr 17, 2017 at 19:25 Douglas Gregor via swift-evolution <swift-evolution at swift.org> wrote:
>> Proposal Link: https://github.com/apple/swift-evolution/blob/master/proposals/0169-improve-interaction-between-private-declarations-and-extensions.md
>> 
>> Hello Swift Community,
>> 
>> The review of SE-0169 "Improve Interaction Between `private` Declarations and Extensions” ran from April 6...11, 2017. The proposal is accepted.
>> 
>> This topic has been highly controversial for a long time, both during Swift 3’s development (when SE-0025 was introduced) and during Swift 4 (including SE-0159 and other proposals). There is no solution that will make everyone happy: maintaining the status quo makes “fileprivate” too common and therefore not meaningful when it occurs in source; removing or diluting scope-level access control (as in SE-0159 and this proposal) takes away a tool that is in use by Swift developers; and adding more levels of access control complicates the language.
>> 
>> The core team feels that this proposal makes private access align more closely with the goals of the language:
>> 
>> It supports the notion that extensions are a code-organization tool: one should be able to break up a type’s definition into several extensions to improve the clarity of that code, without having to open up access or otherwise view the members in different extensions as completely-distinct entities. The core team expects future language evolution to reinforce the notion that extensions are more of a code organization tool than distinct entities, e.g., allowing stored properties to be introduced in an extension.
>> It makes private more usable as the default sub-internal access level, which supports progressive disclosure of the access control system and better matches with programmer’s expectations about what private access means.
>> It makes fileprivate more meaningful, because it is only needed for those cases where one is reaching across types (or among types and globals) within a file. It will also become more rare, which matches well with its longer, descriptive name.
>> 
>> The proposal’s acceptance includes one modification: extensions of a given type that reside in a single file that is different from the file that defines the type itself will have access to the private members of all other extensions in that file. For example:
>> 
>> // FileA.swift
>> struct A {
>>   private var aMember : Int 
>> }
>> 
>> // FileB.swift
>> extension A {
>>     private func foo() {
>>         bar()    // ok, foo() does have access to bar()
>>     }
>> }
>> 
>> extension A {
>>     private func bar() {
>>         aMember = 42  // not ok, private members may not be accessed outside their file.
>>     }
>> }
>> 
>> The proposal has already been updated to reflect this change, which better reflects the notion that extensions are a code-organization tool.
>> 
>> The core team considers the access-control matter closed for Swift 4 and will not be reviewing any further proposals in this area.
>> 
>> 	- Doug
>> 	Review Manager
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170418/0cb0d85c/attachment.html>