On Thu, Apr 6, 2017 at 4:10 PM Douglas Gregor via swift-evolution < swift-evolution@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@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution