The proposal is that the access modifier for an extension will either be removed entirely or remain as an upper bound, losing its function as a default access modifier. The default access modifier rule permits public methods to be written without `public func`; this is a proposal to remove that feature because it is a source of confusion. On Sun, Jul 17, 2016 at 10:43 Adrian Zubarev via swift-evolution < [email protected]> wrote:
> I still don’t catch to point here. There is no implicit public there. > It’s explicit set by the default access modifier of extensions. It’s how > they work and how they should remain (at least as long the community want > default > access modifier to exist on extensions). Disallowing setting public on > extensions when you extend a public type makes no sense. If you want your > member to be internal like it’s in types, then remove the access modifier > from extension and all member will follow the type access modifier. > > > > -- > Adrian Zubarev > Sent with Airmail > > Am 17. Juli 2016 um 17:37:02, Xiaodi Wu ([email protected]) schrieb: > > That's a good point. I will incorporate these into a revised draft. Only > two things will change: > > ``` > public struct Foo { > // implicitly internal > func frobnicate1() { } > } > public extension Foo { > // currently implicitly public > // > // depending on which alternative is adopted, > // the proposal will either prohibit `public extension` > // or this method will be implicitly internal > func frobnicate2() { } > } > ``` > > ``` > internal struct Bar { > // permitted by SE-0025 without a warning > // this method can only be accessed within module anyway > // because `internal struct` bounds access of its members > public func frobnicate1() { } > } > extension Bar { > // not permitted by SE-0025 > // > // after proposal, this will also be permitted without a warning > // and this method will also be accessible only within module > public func frobnicate2() { } > } > ``` > > On Sun, Jul 17, 2016 at 1:50 AM, Adrian Zubarev via swift-evolution < > [email protected]> wrote: > >> I’m struggling to understand your proposal, can you provide some specific >> code samples how it works now and what will change. The example from the >> draft doesn’t help my understanding. :/ >> >> >> -- >> Adrian Zubarev >> Sent with Airmail >> >> Am 17. Juli 2016 um 04:40:45, Xiaodi Wu via swift-evolution ( >> [email protected]) schrieb: >> >> On Sat, Jul 16, 2016 at 7:56 PM, Jose Cheyo Jimenez <[email protected]> >> wrote: >> >>> I think you can simplify this proposal by just saying something like >>> this and give a couple of examples that are easy to follow: >>> >>> Disallow explicit public access modifier on non-protocol-conforming type >>> extensions. >>> >> >> It took me a while to process what you're trying to say here, but this is >> a good idea and would go along well with the first draft's proposed >> solution. I will spell it out. (If we say that you can use an explicit >> modifier only to lower the access level of members, then `public` as an >> explicit modifier could be entirely disallowed.) >> >> >>> >>> I think if you only focus on that breaking change then the proposal will >>> have a good chance of getting accepted and fixing the immediate issue of >>> public. There is a reason why protocol conforming extensions do not allow >>> explicitly saying public >>> `public extension Type: Protocol {}` // public not allowed >>> >> >> Actually, no modifiers are allowed in that scenario, IIUC. >> >>> >>> In essence we will be asking for the same behavior for types. >>> >>> Allowing methods declared inside extensions to have a higher declared >>> visibility is not a breaking change and can be introduced later. >>> >> >> It is a breaking change in that I am proposing that the rules be >> harmonized so that the implicit default access level will be notionally >> `internal` (there are follow-on benefits to this change). That cannot be >> changed later. >> >> >>> Nobody wants private extensions or implicit internal extensions to go >>> away. :) >>> >> >> I know that there are people who don't want it to go away. That was why >> the first draft proposed keeping them, but it sounds like it would make for >> an illogical system. I know that Jordan and John have both indicated that >> they don't think it's worth keeping around but don't seem to feel too >> strongly about it, and I think I feel the same way (leaning towards not >> keeping them, but don't feel very strongly). I will definitely feature this >> concern (using extensions as access modifier groups) prominently in the >> proposal and hope for a robust discussion to see how it plays out with the >> community and core team. >> >> >> >>> On Jul 16, 2016, at 4:22 PM, Xiaodi Wu via swift-evolution < >>> [email protected]> wrote: >>> >>> On Sat, Jul 16, 2016 at 6:10 PM, David Hart <[email protected]> wrote: >>> >>>> This proposal really confuses me. Two comments: >>>> >>>> 1) With the proposal, we loose the ability to use access modifiers on >>>> extensions as a way of grouping members by access. That's a huge loss for >>>> me. >>>> >>> >>> You lose the ability to group public members only. That part is >>> intentional, so that only methods declared with `public func` are public. >>> >>> >>>> 2) If we adopt the proposal, I now have no idea what explicit access >>>> modifiers on extensions do. >>>> >>> >>> I propose keeping explicit access modifiers because previous comments on >>> this list have said that it's useful for grouping members by access. You >>> can continue to use extensions to group fileprivate members of an internal >>> type, or internal members of a public type. >>> >>> >>> >>>> More generally, I don't understand this proposal as it's trying to >>>> apply the same access modifier rules on extensions as for types but >>>> extensions are not types. They are just a declaration for extending types >>>> which already have an access level. >>>> >>>> On 16 Jul 2016, at 20:04, Xiaodi Wu via swift-evolution < >>>> [email protected]> wrote: >>>> >>>> With the impending withdrawal of SE-0119 and the closing window for >>>> (most) source-breaking changes, I thought I'd draft up a proposal to >>>> address some of the key points raised in that discussion. >>>> >>>> The proposed changes are deliberately limited in scope to rationalizing >>>> access modifier rules without adding any new facilities (such as >>>> conformances of lower visibility than the type), which might be more >>>> appropriate for the Swift 4 timeline. >>>> >>>> I hope this will prove satisfactory to the community :) >>>> >>>> >>>> Harmonize access modifiers for extensions >>>> >>>> - Proposal: SE-XXXX >>>> >>>> <https://github.com/xwu/swift-evolution/blob/harmonize-access-modifiers/proposals/XXXX-harmonize-access-modifiers.md> >>>> - Author: Xiaodi Wu <https://github.com/xwu> >>>> - Status: Awaiting review >>>> - Review manager: TBD >>>> >>>> >>>> <https://github.com/xwu/swift-evolution/tree/harmonize-access-modifiers#introduction> >>>> Introduction >>>> >>>> During discussion of SE-0119 >>>> <https://github.com/xwu/swift-evolution/blob/harmonize-access-modifiers/proposals/0119-extensions-access-modifiers>, >>>> the community articulated the view that access modifiers for extensions >>>> were and should continue to be subject to the same rules as access >>>> modifiers for types. Unfortunately, it is not factually true today; this >>>> proposal aims to make it so. >>>> >>>> Swift-evolution threads: >>>> >>>> - [Proposal] Revising access modifiers on extensions >>>> >>>> <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160620/022144.html> >>>> - [More to be added here] >>>> >>>> >>>> <https://github.com/xwu/swift-evolution/tree/harmonize-access-modifiers#motivation> >>>> Motivation >>>> >>>> Consider the following: >>>> >>>> public struct foo { >>>> func frobnicate() { } // implicitly internal >>>> } >>>> public extension foo { } >>>> >>>> public struct bar { } >>>> public extension bar { >>>> func frobnicate() { } // implicitly public, according to SE-0025 >>>> } >>>> >>>> According to SE-0025, a method moved from the body of a public struct >>>> into a public extension becomes public without modification. This is >>>> surprising behavior contrary to Swift's general rule of not exposing public >>>> API by default. >>>> >>>> Furthermore, SE-0025 now permits the owner of a type to design access >>>> for members as though the type will have a higher access level than it >>>> currently does. For example, users will be able to design public methods >>>> inside an internaltype before "flipping the switch" and making that >>>> type public. The same approach is prohibited by SE-0025 for >>>> extensions, although conceptually it need not be. >>>> >>>> <https://github.com/xwu/swift-evolution/tree/harmonize-access-modifiers#proposed-solution>Proposed >>>> solution >>>> >>>> The proposed solution is to change access modifier rules for extensions >>>> with the following effect: if any method (or computed property) declared >>>> within the body of a type at file scope is moved without modification into >>>> the body of an extension in the same file, the move will not change its >>>> accessibility. >>>> >>>> In code: >>>> >>>> struct foo { >>>> // Any method declared here... >>>> } >>>> extension foo { >>>> // ...should have the same visibility when moved here. >>>> } >>>> >>>> This implies that public API commitments will need to be annotated as >>>> public at declaration sites inside an extension just as it must be at >>>> declaration sites inside types. >>>> >>>> <https://github.com/xwu/swift-evolution/tree/harmonize-access-modifiers#detailed-design>Detailed >>>> design >>>> >>>> 1. Declarations inside the extension will, like declarations inside >>>> types, have a default access level of internal. >>>> 2. The compiler should not warn when a broader level of access >>>> control is used for a method (or computed property, etc.) declared >>>> within >>>> an extension with more restrictive access. This allows the owner of the >>>> extension to design the access level they would use for a method if the >>>> type or extension were to be made more widely accessible. >>>> 3. An extension declared without an explicit access modifier will >>>> have the same access level as the type being extended. >>>> 4. An extension declared without protocol conformance may >>>> optionally use an explicit access modifier to provide an upper bound for >>>> the visibility of its members. >>>> >>>> >>>> <https://github.com/xwu/swift-evolution/tree/harmonize-access-modifiers#alternatives-considered>Alternatives >>>> considered >>>> >>>> - One alternative, still open for consideration, is to eliminate #4 >>>> and disallow explicit access modifiers on extensions. As an advantage, >>>> this >>>> would clarify the mental model that extensions are not their own >>>> entities, >>>> as they cannot be referred to by name and have no runtime >>>> representation. >>>> As a disadvantage, extensions cease to be an access modifier grouping >>>> construct, which some users really like. >>>> >>>> >>>> <https://github.com/xwu/swift-evolution/tree/harmonize-access-modifiers#acknowledgments> >>>> Acknowledgments >>>> >>>> Thanks to all discussants on the list, especially Adrian Zubarev and >>>> Jose Cheyo Jimenez. >>>> >>>> _______________________________________________ >>>> 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 >> >> > _______________________________________________ > 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
