[swift-evolution] Enhancing access levels without breaking changes

[Chris Lattner]

> On Apr 12, 2017, at 6:09 AM, Ricardo Parada <rparada at mac.com> wrote:
> 
> 
> On Apr 12, 2017, at 1:42 AM, Chris Lattner via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
> 
>> On Apr 11, 2017, at 10:30 PM, David Hart <david at hartbit.com <mailto:david at hartbit.com>> wrote:
>>>> To me, the reason for limiting it to a file is about predictability, the ability to locally reason about a type, and the need to define some boundary (for symbol visibility reasons).  Saying that extensions to a type have access to private members if they are in the same module is just as arbitrary as limiting it to a single file, and a whole lot less useful from the “reasoning about a type” perspective.
>>> 
>>> I think you misunderstand. We were talking about two extensions of a type, in a different file from the type, to share private members between themselves.
>>> 
>>> Doug Gregor mentioned it during the PR process and we added an example to disallow it, but in hindsight, I think it should be allowed.
>> 
>> Ah, you’re saying:
>> 
>> a.swift:
>> struct X {}
>> 
>> b.swift:
>> extension X {
>>   private func f() {}
>> }
>> 
>> extension X {
>>   func g() { f() }
>> }
>> 
>> If so, then yes, I agree we should accept that.
>> 
>> -Chris
> 
> That would remove the objection I had. It would make the first half and the second half of the proposal consistent. 

Just FYI, I revised the proposal.  It was an oversight/misunderstanding that the proposal indicated the previous approach:
https://github.com/apple/swift-evolution/blob/master/proposals/0169-improve-interaction-between-private-declarations-and-extensions.md

-Chris


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