> On 12 Apr 2017, at 07:42, Chris Lattner <clatt...@nondot.org> wrote: > > On Apr 11, 2017, at 10:30 PM, David Hart <da...@hartbit.com > <mailto: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
Should we edit the proposal or let the Core Team fix it during review as John suggests?
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
