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

[Douglas Gregor]

> On Apr 20, 2017, at 7:53 PM, John McCall <rjmccall at apple.com> wrote:
> 
>> On Apr 20, 2017, at 7:31 PM, Douglas Gregor <dgregor at apple.com <mailto: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).  

I’m saying (2), and I suspect (1) is most often the case… but I agree that we’re likely to end up breaking code here.

> 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.  

I was interpreting SE-0169 to mean this, but you are correct: SE-0169 doesn’t spell out a change here.

> 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. :)

Never put stock in charlatans or compiler writers.

	- Doug


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