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

[Riley Testut]

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.

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 <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 <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <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/1e9b0fb5/attachment.html>