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

Thu Apr 6 19:49:47 CDT 2017

On Thu, Apr 6, 2017 at 7:43 PM, Riley Testut <rileytestut at gmail.com> wrote:

> While valid, my understanding is that the use of extensions that *should *have
> access to private members is more common than the use of extensions to
> explicitly prevent access.
>
> More importantly though, using extensions to prevent access to private
> members can be accomplished by declaring the extensions in another file.
> The reverse is not true; extensions that *should* have access to private
> members is impossible.
>
> tl;dr; using extensions as a means to disallow access to private members
> is (from what I understand) far less common, and if someone really wanted
> to do that, they could instead declare the extensions in another file.
>

Not if those extensions are to access fileprivate members of the type. This
is the same argument that was rejected for SE-0159.

On Apr 6, 2017, at 5:34 PM, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
>
> 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/prop
>> osals/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-declarati
>> ons-and-extensions.md
>>
>>    Reply text
>>
>>        Other replies
>>
>>
>>          <https://github.com/apple/swift-evolution/blob/mast
>> er/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/1374d923/attachment-0001.html>