> On Jul 13, 2016, at 10:26 AM, Xiaodi Wu via swift-evolution > <swift-evolution@swift.org> wrote: > As Jordan mentioned, I don't (and I think other people don't) think of > extensions as their own entities, as they can't be referred to and have no > runtime representation. In that mental model, there isn't such a thing as "an > extension being public." Instead, the access modifier is just a shorthand > default for the properties and methods it contains, which is teachable but > unique to extensions. It is a matter of opinion whether that uniqueness is a > feature or a bug.
I would say that it's interesting but ultimately not worth the confusion about the nature of extensions. John. > > On Wed, Jul 13, 2016 at 12:19 Jose Cheyo Jimenez <ch...@masters3d.com > <mailto:ch...@masters3d.com>> wrote: > > > On Jul 13, 2016, at 8:46 AM, Xiaodi Wu via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: > >> >> >> On Wed, Jul 13, 2016 at 4:04 AM, Rod Brown via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> Proposal link: >> https://github.com/apple/swift-evolution/blob/master/proposals/0119-extensions-access-modifiers.md >> >> <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 >> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> <https://lists.swift.org/mailman/listinfo/swift-evolution> >> >> >> _______________________________________________ >> swift-evolution mailing list >> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> <https://lists.swift.org/mailman/listinfo/swift-evolution> > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
