> On Apr 12, 2017, at 6:09 AM, Ricardo Parada <[email protected]> wrote: > > > On Apr 12, 2017, at 1:42 AM, Chris Lattner via swift-evolution > <[email protected] <mailto:[email protected]>> wrote: > >> On Apr 11, 2017, at 10:30 PM, David Hart <[email protected] >> <mailto:[email protected]>> 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
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
