> On 6 Apr 2017, at 19:41, Jordan Rose via swift-evolution > <swift-evolution@swift.org> wrote: > > 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)
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). > 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 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). > 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. Speaking for someone who uses extensions extensively, I’ve found very little use for private in my own code. > 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? 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. > 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
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
