[swift-evolution] Enhancing access levels without breaking changes
Ricardo Parada
rparada at mac.com
Wed Apr 12 08:09:38 CDT 2017
> On Apr 12, 2017, at 1:42 AM, Chris Lattner via swift-evolution <swift-evolution at swift.org> wrote:
>
> On Apr 11, 2017, at 10:30 PM, David Hart <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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170412/7e9ae274/attachment.html>
More information about the swift-evolution
mailing list