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

[Jose Cheyo Jimenez]

> On Apr 21, 2017, at 8:41 PM, BJ Homer via swift-evolution <swift-evolution at swift.org> wrote:
> 
> The "Access Control" section of the Swift 3 book says the following:
>> You can mark an extension with an explicit access-level modifier (for example, private extension) to set a new default access level for all members defined within the extension.
> The behavior of "private extension" in Swift 3 was a deviation from that model, justified because "private" as a default would have meant that nothing in the extension could ever be called. But it was still contrary to the model suggested by the Swift documentation. 
> 
> Given the highly restrictive behavior of "private" in Swift 3 and the documentation quoted above, it seems unlikely that a developer would intentionally use "private extension" to mean "please make all this stuff visible to the entire file"—it would have worked, but it seems an odd way to write it. If that were the intention, I think "fileprivate extension" would have been more likely.
> 
> I think the change to the behavior of "private extension" is in line with the model proposed by SE-0169, in line with the documented behavior of access control on extensions, and in line with user expectations.
> 
> -BJ

I understand your point. Another aspect of SE-0169 is that fileprivate should be more rare and thus meaningful when used. The current behavior stays true to the goal of making fileprivate rare. 

A top level private scope is effectively fileprivate so it is not totally weird for the extension members to inherit the top level private scope. 

When extensions gain the ability to contain properties, we should not allow the access level modifiers to the extensions in the same way protocol extensions prohibit its use. 


> 
>> On Apr 21, 2017, at 9:30 AM, Douglas Gregor via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>> 
>> 
>>>> 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> wrote:
>>>>>> On Apr 20, 2017, at 3:39 PM, John McCall <rjmccall at apple.com> wrote:
>>>>>> 
>>>>>> On Apr 20, 2017, at 6:35 PM, Xiaodi Wu via swift-evolution <swift-evolution at swift.org> wrote:
>>>>>>> On Thu, Apr 20, 2017 at 5:03 PM, Douglas Gregor <dgregor at apple.com> wrote:
>>>>>>> 
>>>>>>> 
>>>>>>>>> On Apr 20, 2017, at 11:33 AM, Jordan Rose <jordan_rose at apple.com> wrote:
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> On Apr 18, 2017, at 20:40, Douglas Gregor via swift-evolution <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
>> 
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> _______________________________________________
> 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/20170422/53898075/attachment.html>