Hi, -evolution. I’ve said this before, but I think this new proposal is a terrible idea. It privileges types in a way that is damaging to the language.
[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.] 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 1. Extend another type (e.g. converting initializers) 2. Use a helper type (a nested type always inherits the generic parameters of its enclosing type) 3. Break a single protocol or class out into a hierarchy (subtyping should be used sparingly but not never) 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 correct tool for the job. 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 completely indepedent 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. 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 are used organizationally, but there's now no way to distinguish whether the private members of this extension are related to the private members of that extension, or whether they were supposed to be independent. Everyone is acting like "fileprivate" is a problem. While we may not like the name, it's still the right tool for the job. What else do you have in the file that you're trying to protect? Let's not add a mishmash of a feature just because it's "practical" for some uses. Thanks for hearing me out, Jordan P.S. I have a lot 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.
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
