<div dir="ltr">On Tue, Mar 21, 2017 at 12:48 AM, Charles Srstka <span dir="ltr">&lt;<a href="mailto:cocoadev@charlessoft.com" target="_blank">cocoadev@charlessoft.com</a>&gt;</span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><span class="gmail-"><blockquote type="cite">On Mar 21, 2017, at 12:11 AM, Xiaodi Wu via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt; wrote:<br></blockquote><div><blockquote type="cite"><br class="gmail-m_8424419335903052078Apple-interchange-newline"><div><span style="font-family:helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline">Charles Srstka&#39;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 &quot;solves&quot; 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></span><div>I don’t see making things invisible to extensions to be the benefit of ‘private’ at all</div></div></blockquote><div><br></div><div>This feature of new `private` is literally one of the two headline goals outlined in the proposal as it was approved. SE-0025 has written it into the opening sentence: &quot;Scoped access level allows hiding implementation details of a class or a class extension at the class/extension level, instead of a file.&quot; It is absolutely an intended benefit of new `private`. That&#39;s just a factual statement.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div>—it’s for maintaining encapsulation with embedded types. i.e. things like this:</div><div><br></div><div>class Foo {</div><div><span class="gmail-m_8424419335903052078Apple-tab-span" style="white-space:pre-wrap">        </span>class Bar {</div><div><span class="gmail-m_8424419335903052078Apple-tab-span" style="white-space:pre-wrap">                </span>private var baz: String // &lt;— ‘Foo’ doesn’t need to access this</div><div><span class="gmail-m_8424419335903052078Apple-tab-span" style="white-space:pre-wrap">        </span>}</div><div>}</div><div><br></div><div>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><br></div><div>class Foo {</div><div><span class="gmail-m_8424419335903052078Apple-tab-span" style="white-space:pre-wrap">        </span>private var bar: String</div><div>}</div><div><br></div><div>extension Foo: Baz {</div><div><span class="gmail-m_8424419335903052078Apple-tab-span" style="white-space:pre-wrap">        </span>func requiredByBaz() {</div><div><span class="gmail-m_8424419335903052078Apple-tab-span" style="white-space:pre-wrap">                </span>doSomething(with: self.bar) // &lt;— ruh roh</div><div><span class="gmail-m_8424419335903052078Apple-tab-span" style="white-space:pre-wrap">        </span>}</div><div>}</div><div><br></div><div>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&#39;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><span class="gmail-HOEnZb"><font color="#888888"><div><br></div><div>Charles</div><div><br></div></font></span></div></blockquote></div><br></div></div>