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

[Xiaodi Wu]

On Thu, Apr 6, 2017 at 7:28 PM, Riley Testut via swift-evolution <
swift-evolution at swift.org> wrote:

> I cannot express how strongly I believe this *is *the direction Swift
> should go, so a huge, gigantic,
>
> +1
> from me.
>
> After thinking it over, I do not have any qualms with fileprivate itself.
> I think that the functionality provided by fileprivate is valuable, and I
> also agree it shouldn’t be the default.
>
> *However*
>
> This proposal would solve the problems introduced by Swift 3’s private,
> which has resulted in me defaulting to fileprivate for almost all “private”
> variables due to my heavy use of extensions.
>
> Beyond me, however, I can attest that when teaching others Swift, they
> initially are confused why private doesn’t work for extensions. To them, it
> does not feel intuitive, and it certainly doesn’t to me either.
>

`private` works for extensions exactly how the authors of SE-0025 intended
it to do. Your comments do not address what would happen for those people
who are making use of this functionality currently to isolate methods to
the extension only.


> One argument I saw throughout these discussions was that this encourages
> people to put all their code in one file. To that I ask, how is this any
> different than what we have now? Fileprivate doesn’t fix this either.
>
> Ultimately, this keeps things *almost exactly the same* as what we have
> now, but addresses the concerns of many in the Swift community. If you
> don’t want to use private with extensions, people can simply *not use
> private variables in extensions.*
>
> I genuinely believe this will satisfy the majority who were upset by
> fileprivate, and I do not think it will affect those who were in favor of
> fileprivate. So yes, again +10000, and let’s *please* be done with this
> fileprivate/private debate after this.
>
> (Also, I personally don’t view this as a “temporary workaround” like some
> others. I would be very happy if this was the private/fileprivate solution
> forever).
>
> On Apr 6, 2017, at 5:05 PM, Vladimir.S via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> If you don't want to resolve the mistake of SE-0025 by proposing a really
> solution but not a workaround, then just leave the things where they are
> currently. Proposed "improvement" IMO is more confusing than helping.
>
> Sorry, I don't buy <<..most of those proposals are not in scope for
> discussion in Swift 4 (or any later release), given the significant impact
> on source compatibility>>, because SE-0169 is also a source breaking
> change, and the problem of access modifiers is important enough to relax
> the rule of source compatibility for it, *especially if this is the last
> chance*.
> Also, it seems like core team was ready to accept SE-0159(Fix Private
> Access Levels) which also has impact on source compatibility(given it
> suggested to remove scoped-private).
> IMO SE-0159 + new 'scoped' keyword for scoped-private is the solution we
> need.
>
> So, -1 from me.
>
> On 07.04.2017 2:10, Douglas Gregor via swift-evolution 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?
>  * 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
>
>    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
>
> _______________________________________________
> 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/20170406/fd38c9eb/attachment.html>