[swift-evolution] [swift-evolution-announce] [Review] SE-0169: Improve Interaction Between private Declarations and Extensions
shawnce at gmail.com
Fri Apr 7 08:56:15 CDT 2017
-1 (strongish) on this proposal for the reason I comment earlier in the
This weakens private for not an atypical use case of private that I
currently have. It muddies the water between fileprivate and private making
private more confusing and in away surprising. We have a clear and explicit
way in fileprivate to do what this proposal does by tweaking private. I get
that folks don't like fileprivate the word but I don't see that being a
strong enough reason to take things in this direction. It also builds on
file based access scoped which I believe is not the direction we should be
going in a modern language such as swift.
If changes are this strongly desired I believe we should bite the bullet
and rename "private" to "scope[d]" and "fileprivate" to "private". Then
work on making this renamed private work across files coupled either with a
submodule concept (likely tagging wholes file as existing in a module)
and/or making it work across extensions or class trees. ...or as suggested
by others leave "private" as is and just rename "fileprivate" to "shared"
or something like that so it can expand it capability as I outline a
This proposal doesn't help like I think a more comprehensive rework would,
it actually hurts my usage of current private.
On Thu, Apr 6, 2017 at 4:10 PM Douglas Gregor <dgregor at apple.com> 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:
> Reviews are an important part of the Swift evolution process. All reviews
> should be sent to the swift-evolution mailing list at
> 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:
> Reply text
> Other replies
> 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?
> - Is the problem being addressed significant enough to warrant a
> change to Swift?
> - Does this proposal fit well with the feel and direction of Swift?
> - 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?
> More information about the Swift evolution process is available at
> Thank you,
> Review Manager
> swift-evolution-announce mailing list
> swift-evolution-announce at swift.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution