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

[John McCall]

> On Apr 20, 2017, at 7:31 PM, Douglas Gregor <dgregor at apple.com> wrote:
>> On Apr 20, 2017, at 3:39 PM, John McCall <rjmccall at apple.com <mailto:rjmccall at apple.com>> wrote:
>> 
>>> On Apr 20, 2017, at 6:35 PM, Xiaodi Wu via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>> On Thu, Apr 20, 2017 at 5:03 PM, Douglas Gregor <dgregor at apple.com <mailto:dgregor at apple.com>> wrote:
>>> 
>>> 
>>>> On Apr 20, 2017, at 11:33 AM, Jordan Rose <jordan_rose at apple.com <mailto:jordan_rose at apple.com>> wrote:
>>>> 
>>>> 
>>>>> On Apr 18, 2017, at 20:40, Douglas Gregor via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>>>> 
>>>>> 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. 
>>>> 
>>>> Wait, hang on, then people have to write 'fileprivate' instead of 'private' for top-level typealiases (and functions?). 
>>> 
>>> That seems like the correct behavior; private is about members with SE-0169. What do you think?
>>> 
>>> ...that seems suboptimal, given that the goal has been to make it possible for people to use `private` more and not less frequently. IMO, there's no need for `private typealias` at the global level to be prohibited.
>> 
>> Yeah, I see no reason for this to change the behavior of private extensions to be more restrictive than before.
> 
> So you’re okay with:
> 
> 	private extension X {
> 	  func foo() { }
> 	}
> 
> being equivalent to
> 
> 	extension X {
> 	  fileprivate func foo() { }
> 	}
> 
> rather than
> 
> 	extension X {
> 	  private func foo() { }
> 	}
> 
> ?
> 
> That seems unintuitive at best.

Perhaps, but it's existing unintuitive behavior.  Are you suggesting that SE-0169 rationalizes changing it because (1) it's likely that a private extension is just meant for the use of other extensions of that type in the current file and (2) SE-0169 already allows such uses and so justifies the stricter rule?  That is an interesting theory, but I'm not sure I believe (1).  More importantly, though, SE-0169 didn't actually propose changing this behavior, and it's a very substantial shift in behavior, and we haven't actually discussed or gathered any community feedback about it, so I'm really struggling to see why it wouldn't need to be a separate evolution proposal.  And that would be difficult because, as a wise man once said to me, the core team considers the access-control matter closed for Swift 4 and will not be reviewing any further proposals in this area. :)

John.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170420/de3d78f6/attachment.html>