> On Jul 13, 2016, at 8:46 AM, Xiaodi Wu via swift-evolution > <[email protected]> wrote: > > > >> On Wed, Jul 13, 2016 at 4:04 AM, Rod Brown via swift-evolution >> <[email protected]> wrote: >> Proposal link: >> https://github.com/apple/swift-evolution/blob/master/proposals/0119-extensions-access-modifiers.md >> >>> * What is your evaluation of the proposal? >> >> -1. Extensions appear to me to follow the access control of the rest of >> Swift: Implicit to the type you are extending, and you can either / both >> declare as part of the extension declaration or on the method. I don’t see >> how this is confusing, and I expect people will be more confused that >> extensions don’t follow the convention of the rest of Swift for Access >> Control. > > So, actually, the proposal is correct that extensions (at least once > fileprivate/private is implemented) don't follow the access control rules for > the rest of Swift. There is a problem to be addressed. However, I agree that > this proposal hasn't identified the issue or adequately explained how the > solution solves it. Here's the problem I'm thinking of: > > ``` > public struct foo { > func frobnicate() { } // implicitly internal > } > > public struct bar { } > public extension bar { > func frobnicate() { } // implicitly public > // at least, according to the revised rules explained in SE-0025 > } > ```
There is definitely a difference, I think that is a good thing. They look similar but they are completely different. public Type // the type is public public extension Type // the extension is public For extensions, public is just a modifier on extension, not the type. The default scope inside the extension is that of the "modifier" keyword on the extension. This is easy to explain to someone new. > > This is an inconsistency that may (and IMO, really is) worth addressing. If > there's adequate interest, I can circulate a draft with a proposed solution I > have in mind. > >> >>> * Is the problem being addressed significant enough to warrant a change >>> to Swift? >> >> I don’t think this warrants a change. >> >>> * Does this proposal fit well with the feel and direction of Swift? >> No. This seems to go against the 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? >> >> No. >> >>> * How much effort did you put into your review? A glance, a quick >>> reading, or an in-depth study? >> A reading of the proposal. >> >> >> _______________________________________________ >> 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
