I would rather consider using a new keyword that could make it clearer without looking up for description.
New Current moduleprivate over internal On Sat, Oct 8, 2016 at 2:44 PM, Rien via swift-evolution < [email protected]> wrote: > +1 for me. > > I see a little benefit for teams that have multiple people working on a > single file (not necessarily at the same time) where a case can be made for > a distinction between fileprivate and private. Other than that there is imo > no benefit. So to me the question is “is the benefit to those teams worth > the burden on the rest of us”? > > I honestly do not know the answer to that. > > Personally I come down on the side of reverting this change. > > Btw: I was not present during the original discussion. If I had been I > would have tried to make a case for a “friends list”. In which each scope > could have a list of “friends” that have “private” access. This has the > advantage that all external access to the scope would be documentation in > that scope, and it would open up the possibility of granting private access > to closures outside the file the scope was defined in. (private would then > become class-private and fileprivate could be eliminated) > > Rien. > > > On 07 Oct 2016, at 23:44, Tony Allevato via swift-evolution < > [email protected]> wrote: > > > > 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: > >>> > >>> • We should start with the premise that the proposal has added a > substantial amount of complexity: > >>> • It has added an extra modifier and access level to learn. > >>> • It has complicated the access level rules with Inner > types as mentioned in the Complications with private types section of the > proposal. > >>> • 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. > >>> • 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. > >>> • I have the impression that the motivations for the proposal are > much less real in practice: > >>> • 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. > >>> • 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 > > _______________________________________________ > 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
