On Apr 11, 2017, at 10:30 PM, David Hart <da...@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
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution