<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body 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 class=""><br class=""></div><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 class=""><br class=""></div><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 class=""><br class=""></div><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 class=""><br class=""></div><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></body></html>