I still have no idea why you want to make this change, other than "putting an access modifier on an extension is different from putting an access modifier on a type". Are you trying to hide protocol conformances that would be otherwise public? That has much greater consequences and a much stronger domino effect than what you've discussed here.
Jordan > On Jun 27, 2016, at 5:44, Adrian Zubarev via swift-evolution > <[email protected]> wrote: > > Correcting myself over and over. Here is the correct url: > https://github.com/DevAndArtist/swift-evolution/blob/extensions_access_modifiers/proposals/nnnn-extensions-access-modifiers.md > > <https://github.com/DevAndArtist/swift-evolution/blob/extensions_access_modifiers/proposals/nnnn-extensions-access-modifiers.md> > > > > -- > Adrian Zubarev > Sent with Airmail > > Am 27. Juni 2016 um 14:39:41, Adrian Zubarev ([email protected] > <mailto:[email protected]>) schrieb: > >> I completely rewritten the proposal, you can read the formatted version here: >> >> https://github.com/DevAndArtist/swift-evolution/blob/19f2583209a5763880e6f6fa6738ea0c6011f2d6/proposals/nnnn-extensions-access-modifiers.md >> >> <https://github.com/DevAndArtist/swift-evolution/blob/19f2583209a5763880e6f6fa6738ea0c6011f2d6/proposals/nnnn-extensions-access-modifiers.md> >> >> >> -- >> Adrian Zubarev >> Sent with Airmail >> >> Am 27. Juni 2016 um 12:58:53, Adrian Zubarev >> ([email protected] <mailto:[email protected]>) >> schrieb: >> >>> And yet another correction of the default protocol implementations part of >>> my reply. >>> >>> The imported module is correct, but the default implementation is not >>> imported (I relied on Xcode which didn’t raise an error before I started >>> building the project where I was using the module, and I didn’t build it at >>> the first time). >>> >>> So we’d need to implement foo by ourself. >>> >>> struct B : A { >>> >>> public func foo() {} >>> } >>> The rest of my reply should be fine. With the same access control it would >>> be more clearer and intuitive how the extension will be imported. >>> >>> >>> -- >>> Adrian Zubarev >>> Sent with Airmail >>> >>> Am 27. Juni 2016 um 10:38:12, Adrian Zubarev >>> ([email protected] <mailto:[email protected]>) >>> schrieb: >>> >>>> Lets examine the impact on default protocol implementations: >>>> >>>> Currently we have this behavior: >>>> >>>> public protocol A { >>>> func foo() >>>> } >>>> >>>> extension A { >>>> func foo() { /* implement */ } >>>> } >>>> The imported version would look like this. >>>> >>>> public protocol A { >>>> public func foo() >>>> } >>>> As the module user you have no clue that there might be a default >>>> implementation, but you sill will be able to use it, because when >>>> conforming to A you don’t have to implement foo. This implicitly signals >>>> you that there is indeed a default implemenation >>>> >>>> struct B : A {} // This will be enough >>>> >>>> A().foo() // this is fine >>>> One could signal the module user that there is a default implementation by >>>> making the extension explicit public as well. >>>> >>>> // explicitly marked as public to grant visibility to >>>> // the default implementation extension bag >>>> public extension A { >>>> >>>> /// will do something cool >>>> func foo() { /* implement */ } >>>> } >>>> The result of the imported module would change and look like this: >>>> >>>> public protocol A { >>>> public func foo() >>>> } >>>> >>>> extension A { >>>> >>>> /// will do something cool >>>> public func foo() >>>> } >>>> With the proposed change all default implementations will become visible >>>> by default and I think this is great step as well. >>>> >>>> >>> >> > > > _______________________________________________ > 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
