<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=""><blockquote type="cite" class="">On Mar 21, 2017, at 12:11 AM, Xiaodi Wu via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""></blockquote><div><blockquote type="cite" class=""><br class="Apple-interchange-newline"><div class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">Charles Srstka's added comment, while intriguing, poses a problem in argumentation. One of the points being made above about the major advantage of new `private` over `fileprivate` is precisely that new `private` is invisible to extensions. If one "solves" the problem of having to use `fileprivate` by making `private` visible to extensions, it may well be the case that `fileprivate` is no longer commonly necessary--but one has also reverted one of the major arguments in favor of new `private` in the first place.</span></div></blockquote></div><br class=""><div class="">I don’t see making things invisible to extensions to be the benefit of ‘private’ at all—it’s for maintaining encapsulation with embedded types. i.e. things like this:</div><div class=""><br class=""></div><div class="">class Foo {</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>class Bar {</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>private var baz: String // <— ‘Foo’ doesn’t need to access this</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>}</div><div class="">}</div><div class=""><br class=""></div><div class="">This just enforces good programming style. On the other hand, the problem with extensions that people are talking about comes from using extensions to separate sections of a type’s built-in code, mainly around protocol conformances:</div><div class=""><br class=""></div><div class="">class Foo {</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>private var bar: String</div><div class="">}</div><div class=""><br class=""></div><div class="">extension Foo: Baz {</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>func requiredByBaz() {</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>doSomething(with: self.bar) // <— ruh roh</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>}</div><div class="">}</div><div class=""><br class=""></div><div class="">The way I look at it, the extension feature was created with the idea of extending someone else’s type in mind, but the community latched onto it as a way to organize the parts of your own type, and Swift 3’s ‘private’ is getting in the way of that. Broadening ‘private’ to reach in-module extensions would solve this issue, and would *also* allow flexibility to, when the code for an extension gets significantly large relative to the rest of the type's code, split that part off into a different file without needing to make your internal state visible to the entire module. Kill two birds with one stone, so to speak.</div><div class=""><br class=""></div><div class="">Charles</div><div class=""><br class=""></div></body></html>