<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Apr 12, 2017, at 6:09 AM, Ricardo Parada <<a href="mailto:rparada@mac.com" class="">rparada@mac.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="content-type" content="text/html; charset=utf-8" class=""><div dir="auto" class=""><div class=""><br class=""></div><div class="">On Apr 12, 2017, at 1:42 AM, Chris Lattner via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class=""></div><blockquote type="cite" class=""><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class="">On Apr 11, 2017, at 10:30 PM, David Hart <<a href="mailto:david@hartbit.com" class="">david@hartbit.com</a>> wrote:<br class=""><div class=""><blockquote type="cite" class=""><div class=""><div class=""><blockquote type="cite" class="">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.<br class=""></blockquote><br class="">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.<br class=""><br class="">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.<br class=""></div></div></blockquote></div><br class=""><div class="">Ah, you’re saying:</div><div class=""><br class=""></div><div class=""><b class="">a.swift:</b></div><div class="">struct X {}</div><div class=""><br class=""></div><div class=""><b class="">b.swift:</b></div><div class="">extension X {</div><div class=""> private func f() {}</div><div class="">}</div><div class=""><br class=""></div><div class="">extension X {</div><div class=""> func g() { f() }</div><div class="">}</div><div class=""><br class=""></div><div class="">If so, then yes, I agree we should accept that.</div><div class=""><br class=""></div><div class="">-Chris</div></div></blockquote><br class=""><div class="">That would remove the objection I had. It would make the first half and the second half of the proposal consistent. </div></div></div></blockquote></div><br class=""><div class="">Just FYI, I revised the proposal. It was an oversight/misunderstanding that the proposal indicated the previous approach:</div><div class=""><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0169-improve-interaction-between-private-declarations-and-extensions.md" class="">https://github.com/apple/swift-evolution/blob/master/proposals/0169-improve-interaction-between-private-declarations-and-extensions.md</a></div><div class=""><br class=""></div><div class="">-Chris</div><div class=""><br class=""></div><div class=""><br class=""></div></body></html>