[swift-evolution] [Review] SE-0169: Improve Interaction Between private Declarations and Extensions

[Tony Allevato]

On Thu, Apr 6, 2017 at 4:10 PM Douglas Gregor via swift-evolution <
swift-evolution at swift.org> wrote:

> Hello Swift community,
>
> The review of SE-0169 "Improve Interaction Between private Declarations
> and Extensions" begins now and runs through April 11, 2017. The proposal is
> available here:
>
>
> https://github.com/apple/swift-evolution/blob/master/proposals/0169-improve-interaction-between-private-declarations-and-extensions.md
>
> Reviews are an important part of the Swift evolution process. All reviews
> should be sent to the swift-evolution mailing list at
>
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> or, if you would like to keep your feedback private, directly to the
> review manager. When replying, please try to keep the proposal link at the
> top of the message:
>
> Proposal link:
>
>
> https://github.com/apple/swift-evolution/blob/master/proposals/0169-improve-interaction-between-private-declarations-and-extensions.md
>
> Reply text
>
> Other replies
>
>
> <https://github.com/apple/swift-evolution/blob/master/process.md#what-goes-into-a-review-1>What
> goes into a review?
>
> The goal of the review process is to improve the proposal under review
> through constructive criticism and, eventually, determine the direction of
> Swift. When writing your review, here are some questions you might want to
> answer in your review:
>
>    - What is your evaluation of the proposal?
>
> Strong -1.

While I've been strongly against the existence of Swift 3 "private", the
fact is that scoped private is here to stay. If I set my personal biases
aside and look at what this proposal does to scoped private, it muddies the
definition of "private" to the point that it's very confusing.

To describe what I mean, the great thing about Swift 2 visibility was that
it was dead simple to explain what each visibility level applied to:

- public: visible to everyone
- internal: visible in the same module
- private: visible in the same file

Even Swift 3 visibility, with scoped private, has this property:

- public: visible to everyone
- internal: visible in the same module
- fileprivate: visible in the same file
- private: visible in the same scope

Notice that the concept of "type" is nowhere in those definitions. Each
visibility level is based on contiguous physical barriers: the world, the
module, the file, a region bounded by curly braces within a file. But this
change would make the definition of "private" a lot more confusing:

- private: visible in the same scope and extensions to the same type but
only if those extensions are in the same file

It's *much* harder to explain what this "private" means. Does it apply to
scopes? No, it can span scopes because of extensions in the same file. Does
it apply to the same file? No, scopes outside the containing type and its
extensions can't use it. Does it apply to the same type? No, extensions to
the type outside of the containing file can't use it. This "private" is a
hodge-podge of different semantics.

It feels to me that the purpose of this proposal is for people to avoid
typing "fileprivate" which they believe to be ugly. I also think it's ugly,
but I don't want to break the language's visibility model to avoid it.
Furthermore, if the core team's position is that scoped private is valuable
enough and used by enough people that it's worth keeping, then this
proposal unravels it.


>
>    - Is the problem being addressed significant enough to warrant a
>    change to Swift?
>
> No. Until there's a significant need to revisit it (i.e., submodules), we
need to accept that a line has to be drawn *somewhere* with regard to
visibility, and not everyone is going to be 100% happy. It's time to move
on.


>
>    - Does this proposal fit well with the feel and direction of Swift?
>
> No, for the reasons mentioned above (the consistency/contiguity of
visibility regions).


>
>    - If you have used other languages or libraries with a similar
>    feature, how do you feel that this proposal compares to those?
>    - How much effort did you put into your review? A glance, a quick
>    reading, or an in-depth study?
>
> Participation in earlier discussions and a reading of this proposal.



> More information about the Swift evolution process is available at
>
> https://github.com/apple/swift-evolution/blob/master/process.md
>
> Thank you,
>
> -Doug
>
> Review Manager
> _______________________________________________
> 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/20170410/f5564c39/attachment.html>