On Thu, Apr 6, 2017 at 7: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. > 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 <[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/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 >> [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
