I actually feel exactly the opposite of this—personally I thought `private` was fine the way it was when it meant `fileprivate` and I had no real need for `private` as it exists in Swift 3.
`fileprivate` is useful because it lets me organize my code in such a way that I divide large types (for example, those that conform to many delegates/other protocols) into multiple extensions in the same file. Any state or helpers that I want to keep in the main class can be defined as `fileprivate` and still be accessible throughout that file, without leaking them into the rest of my module if they were defined as `internal`. On the other hand, `private` would mostly just protect me from myself at a very small level. In all the Swift code that I've written (this is my anecdotal experience, of course, and I know others differ), it's rare that I've found a strong reason to or benefit from locking something down as `private` instead of `fileprivate`. Of course, one could argue that `fileprivate` is also protecting me from myself, just a file-based level instead of a scope-based level, but I think it would be more harmful to encourage leaking abstractions out of a file and into a module than it would to leak them out of a scope and into a single file. The affected surface area is much smaller in the latter case. One possible compromise that pops into my head would be to let `private` not apply to a scope but to a type and also to only those extensions on that type that are visible in the same file—that may have already been discussed during the review of the original proposal. I don't know what the complexity of it would be. Either way, I would be strongly against anything that removes `fileprivate`. I don't find much use for `private` and nobody is forcing me to use it, so I don't. On the other hand, removing `fileprivate` would prevent a design and code organization pattern that I enjoy about Swift. On Fri, Oct 7, 2016 at 2:06 PM Zach Waldowski via swift-evolution < [email protected]> wrote: > I third this sentiment. fileprivate is a nice idea and very clearly has > its uses (which is why the proposal got traction in the first place), but > when combined with the other access levels, the language feature as a whole > feels arbitrary. In practical use, files that I felt were nicely > encapsulated and hiding implementation details are now a scattered mix of > access levels, adding cognitive load and making the code look unorganized > for having the gall to use extensions to split up functionality. > > Sincerely, > Zachary Waldowski > [email protected] > > > On Fri, Oct 7, 2016, at 01:55 PM, Russ Bishop via swift-evolution wrote: > > > On Oct 7, 2016, at 9:13 AM, David Hart via swift-evolution < > [email protected]> wrote: > > I started the topic, but I also believe like you that the *fileprivate* > vs *private(file)* discussion has already been thoroughly discussed and > nothing new has been brought up. That’s not what I want to discuss. > > I instead want to share my experience using *private* and *fileprivate* > since release. Here are my thoughts: > > > 1. We should start with the premise that the proposal has added a > substantial amount of complexity: > 1. It has added an extra modifier and access level to learn. > 2. It has complicated the access level rules with Inner types as > mentioned in the *Complications with private types* section of the > proposal. > 3. I have seen many people (twitter, work, slack) be confused about > the difference between *private* and *fileprivate* at the global > level. The answer is none, which shows that both modifiers are not very > orthogonal. > 4. Since release, I saw people prefer one over the other, as a > matter of style. They tend to always use *fileprivate* or always > using *private*. In the latter case, functions and properties get > clumped in the same class scope instead of be written through multiple > extensions. > 2. I have the impression that the motivations for the proposal are > much less real in practice: > 1. The first motivation stated is: *"It is not clear whether the > implementation details are meant to be completely hidden or can be > shared > with some related code without the danger of misusing the APIs marked as > private.”* I’ve found that to be fairly rare in practice because > the implementation details only used to leak inside the same file, which > greatly reduces the dangers. > 2. The second motivation stated is: *"It forces a one class per > file structure, which is very limiting." *First of all, this is > partly false. I think it forces putting classes which share > implementation > details in the same file, which I don’t think is necessarily a bad > thing. > > > To summarise, it seems that the confusion the proposal brought over > semantics and style are not worth the limited benefits that it brought. I’d > be tempted to backtrack the proposal and re-introduce private as a file > scoped access-level and deprecate fileprivate. > > Thoughts? > David. > > > > I agree. The minor benefit that fileprivate brings is not worth the > cognitive overhead it introduces. We should just admit it was a mistake and > back it out. We can avoid source-breaking changes by making fileprivate a > synonym for private and provide fixits/warnings for a release to give > people a chance to move off it. > > > > Russ > > *_______________________________________________* > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution > > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
