<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 5, 2017, at 10:30 AM, Chris Lattner via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><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="">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 class=""><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 class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class="">Agreed on both points.</div><div class=""><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 class=""><br class=""></div><div class="">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></div></div></div></blockquote><div><br class=""></div><div>Thanks for jumping in to this thread Chris! It’s always interesting to hear your perspective.</div><div><br class=""></div><div>This makes sharing across types within the file more explicit, but it also makes state that should be tightly encapsulated less explicit unless you create a wrapper type for that state. </div><div><br class=""></div><div>One pattern I have used to good effect is placing this kind of state and the basis operations that manipulate it inside the type declaration and placing operations defined in terms of the basis operations in extensions on the type in the same file. This pattern no longer works as intended under this proposal. In order to migrate code written this way it is necessary to introduce a new type that encapsulates the state and provides the basis operations. This would obviously be a manual migration. I don’t know how many people have adopted styles in Swift 3 that will require manual migration to preserve semantics but it is greater than zero. This is churn that matters and shouldn’t be ignored.</div><div><br class=""></div><div>I suppose a reasonable argument can be made that requiring encapsulation of this kind of state in its own type is a good pattern to that should be encouraged. It certainly calls more attention than the distinction between `private` and `fileprivate` by requiring some boilerplate. The current proposal makes sense to me if you assume that this pattern is worth the boilerplate because it really stands out. It means we encourage the “right” pattern (again, if you agree this pattern is good) and it means we also call special attention to cross-type sharing via `fileprivate` (because as you note it will be more rarely used).</div><div><br class=""></div><div>On the other hand, if you disagree with the argument that we should have to create a new type for this kind of encapsulation then most important question becomes whether it is more important to highlight cross-type sharing within the file or have the convenience of encapsulating fragile state and highlighting it as such without the need to create a new type. IMO highlighting and tightly encapsulating fragile state is a more important concern.</div><div><br class=""></div><div>Do we (the community and the core team) want to encourage programmers to create new types when this kind of encapsulation is needed rather than requiring on lexically scoped access control (that does not cross same-file, same-type extension boundaries)? If yes, then do we think encouraging this and gaining the benefit of highlighting same-file, cross-type interactions are big enough benefits to offset the “hybrid” (type and scope) access control model and another change to the meaning of `private`?</div><div><br class=""></div><div>I like the elegance of a purely scope-based access control model and the tight encapsulation of lexically scoped access control but I can also see some merit in the arguments for this change. I’m interested in hearing any reactions to the lines of reasoning for and against the proposal I have outlined above.</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=""><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 class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class="">struct MyType {</div><div class=""> private var innards : T</div><div class="">}</div><div class=""><br class=""></div><div class="">extension String {</div><div class=""> func myHelper(x : MyType) {</div><div class=""> use(x.innards)</div><div class=""> }</div><div class="">}</div><div class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class="">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 class="">-Chris</div><div class=""><br class=""></div><br class=""></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></body></html>