<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="">On Apr 5, 2017, at 5:13 AM, Michel Fortin <<a href="mailto:michel.fortin@michelf.ca" class="">michel.fortin@michelf.ca</a>> wrote:<br class=""><div><blockquote type="cite" class=""><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><blockquote type="cite" class=""><div class="">Le 5 avr. 2017 à 0:02, Chris Lattner via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> a écrit :</div><br class="Apple-interchange-newline"><div class=""><div style="font-family: SourceSansPro-Regular; font-size: 15px; 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; -webkit-text-stroke-width: 0px;" class=""><div class=""> - fileprivate should really become much more rare, which makes it more meaningful and significant where it occurs. This was the original idea and intent behind SE-0025.</div></div></div></blockquote><div class=""><br class=""></div><div class="">I think this will end up being a flawed assumption, just like last time.</div></div></div></div></blockquote><div><br class=""></div><div>I’m curious to know why you state this, you seem to agree with it below.</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div class="">Granted: there will be less need for `fileprivate` with this. </div></div></div></div></blockquote><div><br class=""></div><div>Right, glad to hear that you agree it will become more rare.</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div class="">Files that implement a type will not need `fileprivate` regardless of how many extensions they use to implement the type. But note that if there is only one type defined in that file (as is often the case), `private` has absolutely the same meaning as `fileprivate`.</div></div></div></div></blockquote><div><br class=""></div><div>Agreed on both points.</div><div><br class=""></div><blockquote type="cite" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div class="">Files that extend multiple types for the purpose of implementing a particular feature will still require `fileprivate` if those extensions want to share some implementation details. </div></div></div></blockquote><div><br class=""></div><div>Right. That’s the part that makes fileprivate more meaningful. This was exactly the *purpose* of having fileprivate in the first place. We want to enable this sort of sharing of private implementation details, but we want to make it explicit at the point of declaration when something like that is going on.</div><br class=""><blockquote type="cite" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div class=""><br class=""></div><blockquote type="cite" class=""><div class=""><div style="font-family: SourceSansPro-Regular; font-size: 15px; 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; -webkit-text-stroke-width: 0px;" class=""><div class=""><div class=""> - Similarly, this simplifies access control for most people. Most people will now only care about private/internal/public. fileprivate will become an expert feature used in specific cases to solve a specific class of problems. Progressive disclosure of complexity is important.</div></div></div></div></blockquote><div class=""><br class=""></div><div class="">People who only care about private/internal/public and ignore `fileprivate` will thus be restricted when it comes to using extensions on multiple types at the same time. If using `fileprivate`indeed becomes rare or discouraged, this will shape the language away from such patterns.</div></div></div></blockquote><div><br class=""></div><div>Again, this is about progressive level of disclosure. It looks like our QoI isn’t good enough right now, but the expected flow is that you write the invalid code (silly example here):</div><div><br class=""></div><div>struct MyType {</div><div> private var innards : T</div><div>}</div><div><br class=""></div><div>extension String {</div><div> func myHelper(x : MyType) {</div><div> use(x.innards)</div><div> }</div><div>}</div><div><br class=""></div><div>You get the standard “innards is inaccessible due to private protection level” error message, but that message should have a note w/FixIt attached to it, offering to upgrade innards to fileprivate.</div><div><br class=""></div><div>This approach is exactly why most people won’t have to care about it … until they need it. At which point, the compiler provides an automatic onramp for them.</div><br class=""><blockquote type="cite" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><blockquote type="cite" class=""><div class=""><div style="font-family: SourceSansPro-Regular; font-size: 15px; 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; -webkit-text-stroke-width: 0px;" class=""><div class=""> - This design is true to the existing design of Swift: we want to encourage the implementation of types to be freely broken into extensions. This alignment with extension oriented programming was the one important virtue of the Swift 1/2 access control design that Swift 3 lost.</div></div></div></blockquote><div class=""><br class=""></div><div class="">This cut both ways. We want to encourage the implementation of types being freely broken into extensions. Great!. But do we want to discourage features implemented as extensions that spans across multiple types?</div></div></div></blockquote><div><br class=""></div><div>We don’t want to discourage them, we want to make them more explicit. This was the intent of SE-0025, and I think the intent was good.</div><br class=""></div><div>-Chris</div><div><br class=""></div><br class=""></body></html>