[swift-evolution] private & fileprivate

[Shawn Erickson]

So are folks saying remove the concept of file private and keep the new
private behavior? ...or revert the whole thing? Also based on what do we
really see an issue with the addition of fileprivate? It seems more theory
then examples of problems in the discussions I have seen.

-Shawn
On Fri, Oct 7, 2016 at 2:05 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/bf045563/attachment.html>