[swift-evolution] private & fileprivate

[Tony Allevato]

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:
>
>
>    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
> 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/20161007/3a5b0ad6/attachment.html>