> On Oct 7, 2016, at 9:13 AM, David Hart via swift-evolution > <swift-evolution@swift.org> 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 swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
