<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 6 Apr 2017, at 19:41, Jordan Rose 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; line-break: after-white-space;" class=""><div class="">Hi, -evolution. I’ve said this before, but <b class="">I think this new proposal is a terrible idea</b>. It privileges types in a way that is damaging to the language.</div><div class=""><br class=""></div><div class="">[There isn't really anything new in my discussion below; everyone on-thread is smart enough to have brought up these points already. But I wanted to go on record about it, at least.]</div><div class=""><br class=""></div><div class="">The claimed problem with the current version of 'private' (let's call it "scoped-private") is that it encourages developers to make monolithic type declarations instead of using extensions. With the proposed new interpretation (let's call it "extension-file-private"), there's a similar problem: developers are encouraged to put everything in the original type even when it may be more appropriate to</div><div class=""><br class=""></div><div class="">1. Extend another type (e.g. converting initializers)</div><div class="">2. Use a helper type (a nested type always inherits the generic parameters of its enclosing type)</div><div class="">3. Break a single protocol or class out into a hierarchy (subtyping should be used <i class="">sparingly</i> but not <i class="">never)</i></div></div></div></blockquote><div><br class=""></div><div>I don’t get that impression. Even with this proposal, fileprivate is readily available to share implementation details with other types in the file. I view this proposal’s version of private very similarly to private in other languages (extensions in the same file as the type feel like part of the type’s scope to me).</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class="">Of course, one can always add an extension to access the extension-file-private members from outside the type, but that just underscores how little expressive power this level would actually have. These are cases where 'fileprivate' is the <i class="">correct</i> tool for the job.</div></div></div></blockquote><div><br class=""></div><div>I don’t feel like this proposal reduces the usefulness of fileprivate, it just makes private more attractive more most cases (i.e., it’s not because public is a good soft-default that open is any less useful).</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class="">I liked the original three levels of access (not a surprise to anyone, since I was a primary designer), and one reason for that is that the access levels are <i class="">completely indepedent</i> of the declarations you're writing. You can organize your code in whatever way makes the most sense, and the access levels will then help you enforce that organization. I do think SE-0025 should not have been accepted, that it does not add enough benefit given the increase to complexity, but even scoped-private can be used as an organizational feature that prevents you from making mistakes, and it still offers a simple answer to where a declaration can be used.</div></div></div></blockquote><div><br class=""></div><div>Speaking for someone who uses extensions extensively, I’ve found very little use for private in my own code.</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class="">The proposed extension-file-private exposes a declaration to an arbitrary subset of the file it's in, because being within an extension of a type or not is arbitrary with regards to code organization. Extensions <i class="">are</i> used organizationally, but there's now no way to distinguish whether the private members of <i class="">this</i> extension are related to the private members of <i class="">that</i> extension, or whether they were supposed to be independent.</div><div class=""><br class=""></div><div class="">Everyone is acting like "fileprivate" is a problem. While we may not like the name, <i class="">it's still the right tool for the job.</i> What else do you have in the file that you're trying to protect?</div></div></div></blockquote><div><br class=""></div><div>If it’s the right tool for the job, then the goal of SE-0025 to make private the soft-default and file private used in rarer occasions have failed. And that’s how I see this proposal: as trying to fix this original goal.</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class="">Let's not add a mishmash of a feature just because it's "practical" for some uses.</div><div class=""><br class=""></div><div class="">Thanks for hearing me out,</div><div class="">Jordan</div><div class=""><br class=""></div><div class="">P.S. I have a <i class="">lot</i> to say on the idea of "submodules", and the dozen different things people want from them. I'll try to write that up later, so that people can refer to it if/when we ever get around to discussing such features. But it's not relevant right now.</div><div class=""><br class=""></div></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>