[swift-evolution] private & fileprivate

Sat Oct 8 02:33:05 CDT 2016

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 <
swift-evolution at swift.org> 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 <
> swift-evolution at swift.org> 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 <
> swift-evolution at swift.org> 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
> >   zach at waldowski.me
> >
> >
> > 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 <
> swift-evolution at 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 at swift.org
> >> https://lists.swift.org/mailman/listinfo/swift-evolution
> >
> > _______________________________________________
> > swift-evolution mailing list
> > swift-evolution at swift.org
> > https://lists.swift.org/mailman/listinfo/swift-evolution
> > _______________________________________________
> > swift-evolution mailing list
> > swift-evolution at swift.org
> > https://lists.swift.org/mailman/listinfo/swift-evolution
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20161008/b178bb4f/attachment.html>