>> `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.
My previous email was in response to this sorry. Ugh, mailing lists. > On Apr 6, 2017, at 5:43 PM, Riley Testut <[email protected]> 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. > >> On Apr 6, 2017, at 5:34 PM, Xiaodi Wu <[email protected]> wrote: >> >>> On Thu, Apr 6, 2017 at 7:28 PM, Riley Testut via swift-evolution >>> <[email protected]> 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 >>>> <[email protected]> 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 >>>>> [email protected] >>>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>>> >>>> _______________________________________________ >>>> swift-evolution mailing list >>>> [email protected] >>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> >>> >>> _______________________________________________ >>> swift-evolution mailing list >>> [email protected] >>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> >>
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
