I agree. I'll post a draft of a proposal surrounding this topic shortly :)
On Sat, Jul 16, 2016 at 12:09 PM, Paul Cantrell via swift-evolution < swift-evolution@swift.org> wrote: > Like others, I do find the details of this proposal hard to follow. It > doesn’t seem like a simpler mental model for developers. > > However, I also find the *current* rules around extension access > modifiers hard to follow. It’s confusing that “public extension” changes > the default for members, when “public class” and “public struct” don’t. And > this is not ideal: > > extension String: Fungible // Extension not “public”, but the > conformance is public? > > IMO, every public API commitment a module makes should include the word > “public” at the declaration site. > > Because of all this, I have stopped using extension-level access modifiers > altogether, instead always specifying access at the member level. I would > be interested in a proposal to improve the current model — perhaps, for > example, making “public extension” apply only to a protocol conformance, > and disabling access modifiers on extensions that don’t have a protocol > conformance. > > Cheers, P > > On Jul 16, 2016, at 11:36 AM, Adrian Zubarev via swift-evolution < > swift-evolution@swift.org> wrote: > > If it’s possible I’d like to withdraw this proposal. I’m convinced by the > feedback from the community. Feel free to reject it. ;) > -- > Adrian Zubarev > Sent with Airmail > > Am 13. Juli 2016 um 19:33:00, John McCall via swift-evolution ( > swift-evolution@swift.org) schrieb: > > 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> > wrote: > >> >> >> On Jul 13, 2016, at 8:46 AM, Xiaodi Wu via swift-evolution < >> swift-evolution@swift.org> wrote: >> >> >> >> On Wed, Jul 13, 2016 at 4:04 AM, Rod Brown via swift-evolution < >> swift-evolution@swift.org> 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 >>> 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 >> >> _______________________________________________ > 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 > > > _______________________________________________ > 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 > >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
