# \[Late Pitch\] open/public protocols **URL:** \ **Category:** Discussion\ **Created:** [August 22, 2016, 6:40pm UTC](https://forums.swift.org/t/late-pitch-open-public-protocols/3834 "2016-08-22T18:40:44Z")\ **Posts on this page:** 11\ **Page:** 1
**Author:** ![DevAndArtist](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/devandartist/32/287_2.png) [@DevAndArtist](https://forums.swift.org/u/DevAndArtist)\ **Post date:** [August 22, 2016, 6:40pm UTC](https://forums.swift.org/t/late-pitch-open-public-protocols/3834/1 "2016-08-22T18:40:44Z")
Hello dear Swift community, I was updating some of my libraries where I noticed that the new open access modifier made the public modifier inconsistent in one way. Conformances to protocols is logically the same as inheritances on classes. Conformances == (abstract) inheritance That said we should allow protocols to be open/public like we now allow this distinction for classes. open protocol from module A should mean that I’m allowed to conform to it in module B public protocol will act as an interface in module B Not only sounds this behavior like ‘nice to have’, it’s inconsistency and it’s a ‘really need’ + a source breaking change in general. A common mistake in Swift 3.0 would be to hide protocol members behind public modifier for protocols that meant to be open. If a protocol member in an open class is disallowed to be overridden by the public modifier and this behavior is fixed, that will imply that you’ll have to open the member which you intended to be not overridable. // Before: // In module A public protocol Proto {   func doSomething() } open class Base : Proto {   // Dissallow to override - this would be a common mistake   public func doSomething() {} } // Used in module B - so it should be `open` after all class Test : Proto { func doSomething() {} } // After: // In module A open protocol Proto {   func doSomething() } open class Base : Proto {   // Whops we have to grant the ability to override this method now   // I made a mistake designing my protocol in Swift 3.0 :/   open func doSomething() {} } // In module B class Test2 : Base {   // Uuuuuuh I can do bad things with this now if the module A was not redesigned to fix this. :)))   override func doSomething() {} } Personally I don’t have any feeling of how huge the impact might be on Swift if this behavior will be fixed. I also cannot tell if it’s something for Swift 3.x or Swift 4.0. > **···** > > -- > Adrian Zubarev > Sent with Airmail ---
**Author:** ![Tino](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/tino/32/1073_2.png) [@Tino](https://forums.swift.org/u/Tino)\ **Post date:** [August 23, 2016, 9:53am UTC](https://forums.swift.org/t/late-pitch-open-public-protocols/3834/2 "2016-08-23T09:53:55Z")
> I was updating some of my libraries where I noticed that the new open access modifier made the public modifier inconsistent in one way. > > Conformances to protocols is logically the same as inheritances on classes. At least it is very, very similar, and most of the syntax is identical. Considering the demand for "sealed" protocols, imho this inconsistency should be addressed as soon as possible. Afair, the decision for "public as restriction of open" happened quite quickly… I guess simply adding "sealed" would have spared Swift from a huge, breaking change and avoided the protocol-issue as well. Tino ---
**Author:** ![Kevin\_Lundberg](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/kevin_lundberg/32/353_2.png) [@Kevin\_Lundberg](https://forums.swift.org/u/Kevin_Lundberg)\ **Post date:** [August 25, 2016, 5:01am UTC](https://forums.swift.org/t/late-pitch-open-public-protocols/3834/3 "2016-08-25T05:01:23Z")
> Hello dear Swift community, > > I was updating some of my libraries where I noticed that the new > \>open\> access modifier made the |public| modifier inconsistent in one way. > > Conformances to protocols is logically the same as inheritances on > classes. I don't understand why this is the case. From a practical perspective, non-open classes by default were pushed in order to guard against the fragile base class problem. Classes always carry implementations with the methods you can override, while protocols don't (in the same way). A "fragile base protocol extension implementation" problem can be avoided today by designing your protocols properly. Not to mention that by definition, protocols are designed to be conformed to by other types, while not all classes are designed to be subclassed. What problem aside from a perceived inconsistency would allowing for non-open protocols by default solve? >   \* |Conformances == (abstract) inheritance| > > That said we should allow protocols to be |open/public| like we now > allow this distinction for classes. > >   \* |open protocol| from module A should mean that I’m allowed to >     conform to it in module B >   \* |public protocol| will act as an interface in module B > > Not only sounds this behavior like ‘nice to have’, it’s inconsistency > and it’s a ‘really need’ + a source breaking change in general. > > A common mistake in Swift 3.0 would be to hide protocol members behind > \>public\> modifier for protocols that meant to be |open|. If a protocol > member in an open class is disallowed to be overridden by the |public| > modifier and this behavior is fixed, that will imply that you’ll have > to open the member which you intended to be not overridable. > > \>// Before: // In module A public protocol Proto { func doSomething() } > open class Base : Proto { // Dissallow to override - this would be a > common mistake public func doSomething() {} } // Used in module B - so > it should be `open` after all class Test : Proto { func doSomething() > {} } // After: // In module A open protocol Proto { func doSomething() > } open class Base : Proto { // Whops we have to grant the ability to > override this method now // I made a mistake designing my protocol in > Swift 3.0 :/ open func doSomething() {} } // In module B class Test2 : > Base { // Uuuuuuh I can do bad things with this now if the module A > was not redesigned to fix this. :))) override func doSomething() {} } | This example is a little confusing; do you mean that if protocols are given the same open semantics as classes that there would be a cross-module implementation problem? If so, isn't that an argument against this? I don't see a problem with just letting the class's open/public modifier be the last word on any implemented public protocols. If a public protocol is applied to an open class, then that protocol method should be allowed to be declared as either open or public, which should be enough to satisfy the protocol conformance from the protocol's perspective. > **···** > > On 8/22/2016 2:40 PM, Adrian Zubarev via swift-evolution wrote: > > > Personally I don’t have any feeling of how huge the impact might be on > > Swift if this behavior will be fixed. I also cannot tell if it’s > > something for Swift 3.x or Swift 4.0. > > > > -- > > Adrian Zubarev > > Sent with Airmail > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > swift-evolution mailing list > > swift-evolution@swift.org > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) ---
**Author:** ![Karl](https://avatars.discourse-cdn.com/v4/letter/k/34f0e0/32.png) [@Karl](https://forums.swift.org/u/Karl)\ **Post date:** [August 25, 2016, 9:29am UTC](https://forums.swift.org/t/late-pitch-open-public-protocols/3834/4 "2016-08-25T09:29:11Z")
This is not a new inconsistency. We’ve known about this since “open” was first proposed. Having sealed protocols would be nice, but it’s too late for Swift 3 IMO. Karl > **···** > > > On 22 Aug 2016, at 20:40, Adrian Zubarev via swift-evolution \ wrote: > > > > Hello dear Swift community, > > > > I was updating some of my libraries where I noticed that the new open access modifier made the public modifier inconsistent in one way. > > > > Conformances to protocols is logically the same as inheritances on classes. > > > > Conformances == (abstract) inheritance > > That said we should allow protocols to be open/public like we now allow this distinction for classes. > > > > open protocol from module A should mean that I’m allowed to conform to it in module B > > public protocol will act as an interface in module B > > Not only sounds this behavior like ‘nice to have’, it’s inconsistency and it’s a ‘really need’ + a source breaking change in general. > > > > A common mistake in Swift 3.0 would be to hide protocol members behind public modifier for protocols that meant to be open. If a protocol member in an open class is disallowed to be overridden by the public modifier and this behavior is fixed, that will imply that you’ll have to open the member which you intended to be not overridable. > > > > // Before: > > > > // In module A > > public protocol Proto { > >   func doSomething() > > } > > > > open class Base : Proto { > >   // Dissallow to override - this would be a common mistake > >   public func doSomething() {} > > } > > > > // Used in module B - so it should be `open` after all > > class Test : Proto { > > func doSomething() {} > > } > > > > // After: > > // In module A > > open protocol Proto { > >   func doSomething() > > } > > > > open class Base : Proto { > >   // Whops we have to grant the ability to override this method now > >   // I made a mistake designing my protocol in Swift 3.0 :/ > >   open func doSomething() {} > > } > > > > // In module B > > class Test2 : Base { > >   // Uuuuuuh I can do bad things with this now if the module A was not redesigned to fix this. :))) > >   override func doSomething() {} > > } > > Personally I don’t have any feeling of how huge the impact might be on Swift if this behavior will be fixed. I also cannot tell if it’s something for Swift 3.x or Swift 4.0. > > > > -- > > Adrian Zubarev > > Sent with Airmail > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > swift-evolution mailing list > > swift-evolution@swift.org \ > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) ---
**Author:** ![John\_McCall](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/john_mccall/32/1351_2.png) [@John\_McCall](https://forums.swift.org/u/John_McCall)\ **Post date:** [August 25, 2016, 5:29pm UTC](https://forums.swift.org/t/late-pitch-open-public-protocols/3834/5 "2016-08-25T17:29:05Z")
> This is not a new inconsistency. We’ve known about this since “open” was first proposed. > > Having sealed protocols would be nice, but it’s too late for Swift 3 IMO. Everything is too late for Swift 3. Bug fixes are about to be too late for Swift 3, much less any actual language changes. John. > **···** > > > On Aug 25, 2016, at 2:29 AM, Karl via swift-evolution \ wrote: > > > Karl > > > > > On 22 Aug 2016, at 20:40, Adrian Zubarev via swift-evolution \\> wrote: > > > > > > Hello dear Swift community, > > > > > > I was updating some of my libraries where I noticed that the new open access modifier made the public modifier inconsistent in one way. > > > > > > Conformances to protocols is logically the same as inheritances on classes. > > > > > > Conformances == (abstract) inheritance > > > That said we should allow protocols to be open/public like we now allow this distinction for classes. > > > > > > open protocol from module A should mean that I’m allowed to conform to it in module B > > > public protocol will act as an interface in module B > > > Not only sounds this behavior like ‘nice to have’, it’s inconsistency and it’s a ‘really need’ + a source breaking change in general. > > > > > > A common mistake in Swift 3.0 would be to hide protocol members behind public modifier for protocols that meant to be open. If a protocol member in an open class is disallowed to be overridden by the public modifier and this behavior is fixed, that will imply that you’ll have to open the member which you intended to be not overridable. > > > > > > // Before: > > > > > > // In module A > > > public protocol Proto { > > >   func doSomething() > > > } > > > > > > open class Base : Proto { > > >   // Dissallow to override - this would be a common mistake > > >   public func doSomething() {} > > > } > > > > > > // Used in module B - so it should be `open` after all > > > class Test : Proto { > > > func doSomething() {} > > > } > > > > > > // After: > > > // In module A > > > open protocol Proto { > > >   func doSomething() > > > } > > > > > > open class Base : Proto { > > >   // Whops we have to grant the ability to override this method now > > >   // I made a mistake designing my protocol in Swift 3.0 :/ > > >   open func doSomething() {} > > > } > > > > > > // In module B > > > class Test2 : Base { > > >   // Uuuuuuh I can do bad things with this now if the module A was not redesigned to fix this. :))) > > >   override func doSomething() {} > > > } > > > Personally I don’t have any feeling of how huge the impact might be on Swift if this behavior will be fixed. I also cannot tell if it’s something for Swift 3.x or Swift 4.0. > > > > > > -- > > > Adrian Zubarev > > > Sent with Airmail > > > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > > swift-evolution mailing list > > > 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](https://lists.swift.org/mailman/listinfo/swift-evolution) ---
**Author:** ![DevAndArtist](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/devandartist/32/287_2.png) [@DevAndArtist](https://forums.swift.org/u/DevAndArtist)\ **Post date:** [October 7, 2016, 4:40pm UTC](https://forums.swift.org/t/late-pitch-open-public-protocols/3834/6 "2016-10-07T16:40:27Z")
Shall we revive this discussion? > **···** > > -- > Adrian Zubarev > Sent with Airmail > > Am 25. August 2016 um 19:29:13, John McCall (rjmccall@apple.com) schrieb: > > On Aug 25, 2016, at 2:29 AM, Karl via swift-evolution \ wrote: > This is not a new inconsistency. We’ve known about this since “open” was first proposed. > > Having sealed protocols would be nice, but it’s too late for Swift 3 IMO. > > Everything is too late for Swift 3. Bug fixes are about to be too late for Swift 3, much less any actual language changes. > > John. > > Karl > > On 22 Aug 2016, at 20:40, Adrian Zubarev via swift-evolution \ wrote: > > Hello dear Swift community, > > I was updating some of my libraries where I noticed that the new open access modifier made the public modifier inconsistent in one way. > > Conformances to protocols is logically the same as inheritances on classes. > > Conformances == (abstract) inheritance > That said we should allow protocols to be open/public like we now allow this distinction for classes. > > open protocol from module A should mean that I’m allowed to conform to it in module B > public protocol will act as an interface in module B > Not only sounds this behavior like ‘nice to have’, it’s inconsistency and it’s a ‘really need’ + a source breaking change in general. > > A common mistake in Swift 3.0 would be to hide protocol members behind public modifier for protocols that meant to be open. If a protocol member in an open class is disallowed to be overridden by the public modifier and this behavior is fixed, that will imply that you’ll have to open the member which you intended to be not overridable. > > // Before: > > // In module A > public protocol Proto { >   func doSomething() > } > > open class Base : Proto { >   // Dissallow to override - this would be a common mistake >   public func doSomething() {} > } > > // Used in module B - so it should be `open` after all > class Test : Proto { > func doSomething() {} > } > > // After: > // In module A > open protocol Proto { >   func doSomething() > } > > open class Base : Proto { >   // Whops we have to grant the ability to override this method now >   // I made a mistake designing my protocol in Swift 3.0 :/ >   open func doSomething() {} > } > > // In module B > class Test2 : Base { >   // Uuuuuuh I can do bad things with this now if the module A was not redesigned to fix this. :))) >   override func doSomething() {} > } > Personally I don’t have any feeling of how huge the impact might be on Swift if this behavior will be fixed. I also cannot tell if it’s something for Swift 3.x or Swift 4.0. > > -- > Adrian Zubarev > Sent with Airmail > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > swift-evolution mailing list > 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](https://lists.swift.org/mailman/listinfo/swift-evolution) ---
**Author:** ![Panajev](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/panajev/32/1227_2.png) [@Panajev](https://forums.swift.org/u/Panajev)\ **Post date:** [October 7, 2016, 5:44pm UTC](https://forums.swift.org/t/late-pitch-open-public-protocols/3834/7 "2016-10-07T17:44:03Z")
I would say we should, I think we moved a bit hastily and the strict push for non subclassable by default and the sealed by default discussion may still yield nasty side effects that are exponentially costlier as we move to Swift 4+ > **···** > > Sent from my iPhone > > > On 7 Oct 2016, at 17:40, Adrian Zubarev via swift-evolution \ wrote: > > > > Shall we revive this discussion? > > > > -- > > Adrian Zubarev > > Sent with Airmail > > > > Am 25. August 2016 um 19:29:13, John McCall (rjmccall@apple.com) schrieb: > > > > > > On Aug 25, 2016, at 2:29 AM, Karl via swift-evolution \ wrote: > > > > This is not a new inconsistency. We’ve known about this since “open” was first proposed. > > > > > > > > Having sealed protocols would be nice, but it’s too late for Swift 3 IMO. > > > > > > Everything is too late for Swift 3. Bug fixes are about to be too late for Swift 3, much less any actual language changes. > > > > > > John. > > > > > > > Karl > > > > > > > > > On 22 Aug 2016, at 20:40, Adrian Zubarev via swift-evolution \ wrote: > > > > > > > > > > Hello dear Swift community, > > > > > > > > > > I was updating some of my libraries where I noticed that the new open access modifier made the public modifier inconsistent in one way. > > > > > > > > > > Conformances to protocols is logically the same as inheritances on classes. > > > > > > > > > > Conformances == (abstract) inheritance > > > > > That said we should allow protocols to be open/public like we now allow this distinction for classes. > > > > > > > > > > open protocol from module A should mean that I’m allowed to conform to it in module B > > > > > public protocol will act as an interface in module B > > > > > Not only sounds this behavior like ‘nice to have’, it’s inconsistency and it’s a ‘really need’ + a source breaking change in general. > > > > > > > > > > A common mistake in Swift 3.0 would be to hide protocol members behind public modifier for protocols that meant to be open. If a protocol member in an open class is disallowed to be overridden by the public modifier and this behavior is fixed, that will imply that you’ll have to open the member which you intended to be not overridable. > > > > > > > > > > // Before: > > > > > > > > > > // In module A > > > > > public protocol Proto { > > > > >   func doSomething() > > > > > } > > > > > > > > > > open class Base : Proto { > > > > >   // Dissallow to override - this would be a common mistake > > > > >   public func doSomething() {} > > > > > } > > > > > > > > > > // Used in module B - so it should be `open` after all > > > > > class Test : Proto { > > > > > func doSomething() {} > > > > > } > > > > > > > > > > // After: > > > > > // In module A > > > > > open protocol Proto { > > > > >   func doSomething() > > > > > } > > > > > > > > > > open class Base : Proto { > > > > >   // Whops we have to grant the ability to override this method now > > > > >   // I made a mistake designing my protocol in Swift 3.0 :/ > > > > >   open func doSomething() {} > > > > > } > > > > > > > > > > // In module B > > > > > class Test2 : Base { > > > > >   // Uuuuuuh I can do bad things with this now if the module A was not redesigned to fix this. :))) > > > > >   override func doSomething() {} > > > > > } > > > > > Personally I don’t have any feeling of how huge the impact might be on Swift if this behavior will be fixed. I also cannot tell if it’s something for Swift 3.x or Swift 4.0. > > > > > > > > > > -- > > > > > Adrian Zubarev > > > > > Sent with Airmail > > > > > > > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > > > > swift-evolution mailing list > > > > > 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](https://lists.swift.org/mailman/listinfo/swift-evolution) > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > swift-evolution mailing list > > swift-evolution@swift.org > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) ---
**Author:** ![John\_McCall](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/john_mccall/32/1351_2.png) [@John\_McCall](https://forums.swift.org/u/John_McCall)\ **Post date:** [October 7, 2016, 6:55pm UTC](https://forums.swift.org/t/late-pitch-open-public-protocols/3834/8 "2016-10-07T18:55:22Z")
> I would say we should, I think we moved a bit hastily and the strict push for non subclassable by default and the sealed by default discussion may still yield nasty side effects that are exponentially costlier as we move to Swift 4+ It sounds like you're talking about re-opening the public/open class discussion, which is not the discussion I understand Adrian to be asking about. If people would like to talk about adding some way to express a protocol that can be implemented only internally but still used elsewhere, they should feel free. The core team isn't inviting that kind of formal proposal yet, but that shouldn't prevent any discussion here. However, please understand that changing the interpretation of "public" would be a source-breaking change and therefore needs to meet a much higher bar in 4.0 than it would have in 3.0; that may significantly shape your discussion. John. > **···** > > > On Oct 7, 2016, at 10:44 AM, Goffredo Marocchi \ wrote: > > > Sent from my iPhone > > > > On 7 Oct 2016, at 17:40, Adrian Zubarev via swift-evolution \\> wrote: > > > > > Shall we revive this discussion? > > > > > > -- > > > Adrian Zubarev > > > Sent with Airmail > > > > > > Am 25. August 2016 um 19:29:13, John McCall (rjmccall@apple.com \) schrieb: > > > > > > > > On Aug 25, 2016, at 2:29 AM, Karl via swift-evolution \\> wrote: > > > > > This is not a new inconsistency. We’ve known about this since “open” was first proposed. > > > > > > > > > > Having sealed protocols would be nice, but it’s too late for Swift 3 IMO. > > > > > > > > Everything is too late for Swift 3. Bug fixes are about to be too late for Swift 3, much less any actual language changes. > > > > > > > > John. > > > > > > > > > Karl > > > > > > > > > > > On 22 Aug 2016, at 20:40, Adrian Zubarev via swift-evolution \\> wrote: > > > > > > > > > > > > Hello dear Swift community, > > > > > > > > > > > > I was updating some of my libraries where I noticed that the new open access modifier made the public modifier inconsistent in one way. > > > > > > > > > > > > Conformances to protocols is logically the same as inheritances on classes. > > > > > > > > > > > > Conformances == (abstract) inheritance > > > > > > That said we should allow protocols to be open/public like we now allow this distinction for classes. > > > > > > > > > > > > open protocol from module A should mean that I’m allowed to conform to it in module B > > > > > > public protocol will act as an interface in module B > > > > > > Not only sounds this behavior like ‘nice to have’, it’s inconsistency and it’s a ‘really need’ + a source breaking change in general. > > > > > > > > > > > > A common mistake in Swift 3.0 would be to hide protocol members behind public modifier for protocols that meant to be open. If a protocol member in an open class is disallowed to be overridden by the public modifier and this behavior is fixed, that will imply that you’ll have to open the member which you intended to be not overridable. > > > > > > > > > > > > // Before: > > > > > > > > > > > > // In module A > > > > > > public protocol Proto { > > > > > >   func doSomething() > > > > > > } > > > > > > > > > > > > open class Base : Proto { > > > > > >   // Dissallow to override - this would be a common mistake > > > > > >   public func doSomething() {} > > > > > > } > > > > > > > > > > > > // Used in module B - so it should be `open` after all > > > > > > class Test : Proto { > > > > > > func doSomething() {} > > > > > > } > > > > > > > > > > > > // After: > > > > > > // In module A > > > > > > open protocol Proto { > > > > > >   func doSomething() > > > > > > } > > > > > > > > > > > > open class Base : Proto { > > > > > >   // Whops we have to grant the ability to override this method now > > > > > >   // I made a mistake designing my protocol in Swift 3.0 :/ > > > > > >   open func doSomething() {} > > > > > > } > > > > > > > > > > > > // In module B > > > > > > class Test2 : Base { > > > > > >   // Uuuuuuh I can do bad things with this now if the module A was not redesigned to fix this. :))) > > > > > >   override func doSomething() {} > > > > > > } > > > > > > Personally I don’t have any feeling of how huge the impact might be on Swift if this behavior will be fixed. I also cannot tell if it’s something for Swift 3.x or Swift 4.0. > > > > > > > > > > > > -- > > > > > > Adrian Zubarev > > > > > > Sent with Airmail > > > > > > > > > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > > > > > swift-evolution mailing list > > > > > > 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](https://lists.swift.org/mailman/listinfo/swift-evolution) > > > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > > swift-evolution mailing list > > > swift-evolution@swift.org \ > > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) ---
**Author:** ![BigZaphod](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/bigzaphod/32/9561_2.png) [@BigZaphod](https://forums.swift.org/u/BigZaphod)\ **Post date:** [October 7, 2016, 5:50pm UTC](https://forums.swift.org/t/late-pitch-open-public-protocols/3834/9 "2016-10-07T17:50:58Z")
I don’t disagree that there may have been some hasty movement on this originally, but I don’t think the solution is to move hastily again and second-guess everything before the dust has even had time to settle. l8r Sean > **···** > > > On Oct 7, 2016, at 12:44 PM, Goffredo Marocchi via swift-evolution \ wrote: > > > > I would say we should, I think we moved a bit hastily and the strict push for non subclassable by default and the sealed by default discussion may still yield nasty side effects that are exponentially costlier as we move to Swift 4+ > > > > Sent from my iPhone > > > > On 7 Oct 2016, at 17:40, Adrian Zubarev via swift-evolution \ wrote: > > > > > Shall we revive this discussion? > > > > > > -- > > > Adrian Zubarev > > > Sent with Airmail > > > > > > Am 25. August 2016 um 19:29:13, John McCall (rjmccall@apple.com) schrieb: > > > > > > > > On Aug 25, 2016, at 2:29 AM, Karl via swift-evolution \ wrote: > > > > > This is not a new inconsistency. We’ve known about this since “open” was first proposed. > > > > > > > > > > Having sealed protocols would be nice, but it’s too late for Swift 3 IMO. > > > > > > > > Everything is too late for Swift 3. Bug fixes are about to be too late for Swift 3, much less any actual language changes. > > > > > > > > John. > > > > > > > > > Karl > > > > > > > > > > > On 22 Aug 2016, at 20:40, Adrian Zubarev via swift-evolution \ wrote: > > > > > > > > > > > > Hello dear Swift community, > > > > > > > > > > > > I was updating some of my libraries where I noticed that the new open access modifier made the public modifier inconsistent in one way. > > > > > > > > > > > > Conformances to protocols is logically the same as inheritances on classes. > > > > > > > > > > > >   • Conformances == (abstract) inheritance > > > > > > That said we should allow protocols to be open/public like we now allow this distinction for classes. > > > > > > > > > > > >   • open protocol from module A should mean that I’m allowed to conform to it in module B > > > > > >   • public protocol will act as an interface in module B > > > > > > Not only sounds this behavior like ‘nice to have’, it’s inconsistency and it’s a ‘really need’ + a source breaking change in general. > > > > > > > > > > > > A common mistake in Swift 3.0 would be to hide protocol members behind public modifier for protocols that meant to be open. If a protocol member in an open class is disallowed to be overridden by the public modifier and this behavior is fixed, that will imply that you’ll have to open the member which you intended to be not overridable. > > > > > > > > > > > > // Before: > > > > > > > > > > > > // In module A > > > > > > public protocol Proto { > > > > > >   func doSomething() > > > > > > } > > > > > > > > > > > > open class Base : Proto { > > > > > >   // Dissallow to override - this would be a common mistake > > > > > >   public func doSomething() {} > > > > > > } > > > > > > > > > > > > // Used in module B - so it should be `open` after all > > > > > > class Test : Proto { > > > > > > func doSomething() {} > > > > > > } > > > > > > > > > > > > // After: > > > > > > // In module A > > > > > > open protocol Proto { > > > > > >   func doSomething() > > > > > > } > > > > > > > > > > > > open class Base : Proto { > > > > > >   // Whops we have to grant the ability to override this method now > > > > > >   // I made a mistake designing my protocol in Swift 3.0 :/ > > > > > >   open func doSomething() {} > > > > > > } > > > > > > > > > > > > // In module B > > > > > > class Test2 : Base { > > > > > >   // Uuuuuuh I can do bad things with this now if the module A was not redesigned to fix this. :))) > > > > > >   override func doSomething() {} > > > > > > } > > > > > > > > > > > > Personally I don’t have any feeling of how huge the impact might be on Swift if this behavior will be fixed. I also cannot tell if it’s something for Swift 3.x or Swift 4.0. > > > > > > > > > > > > -- > > > > > > Adrian Zubarev > > > > > > Sent with Airmail > > > > > > > > > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > > > > > swift-evolution mailing list > > > > > > 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](https://lists.swift.org/mailman/listinfo/swift-evolution) > > > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > > swift-evolution mailing list > > > 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](https://lists.swift.org/mailman/listinfo/swift-evolution) ---
**Author:** ![Panajev](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/panajev/32/1227_2.png) [@Panajev](https://forums.swift.org/u/Panajev)\ **Post date:** [October 7, 2016, 6:05pm UTC](https://forums.swift.org/t/late-pitch-open-public-protocols/3834/10 "2016-10-07T18:05:28Z")
True too, but dust settling will mean that for each speck the justification burden will rise quite massively. Not fixing this for Swift 4 phase 1 may mean a breaking change very very hard to justify for Swift 4 phase 2 which is for additive changes IIRC and even harder for Swift 5 and harder again on Swift 6 unless I am missing the core team vision for Swift's evolution. > **···** > > Sent from my iPhone > > > On 7 Oct 2016, at 18:50, Sean Heber \ wrote: > > > > I don’t disagree that there may have been some hasty movement on this originally, but I don’t think the solution is to move hastily again and second-guess everything before the dust has even had time to settle. > > > > l8r > > Sean > > > > > On Oct 7, 2016, at 12:44 PM, Goffredo Marocchi via swift-evolution \ wrote: > > > > > > I would say we should, I think we moved a bit hastily and the strict push for non subclassable by default and the sealed by default discussion may still yield nasty side effects that are exponentially costlier as we move to Swift 4+ > > > > > > Sent from my iPhone > > > > > > > On 7 Oct 2016, at 17:40, Adrian Zubarev via swift-evolution \ wrote: > > > > > > > > Shall we revive this discussion? > > > > > > > > -- > > > > Adrian Zubarev > > > > Sent with Airmail > > > > > > > > Am 25. August 2016 um 19:29:13, John McCall (rjmccall@apple.com) schrieb: > > > > > > > > > > On Aug 25, 2016, at 2:29 AM, Karl via swift-evolution \ wrote: > > > > > > This is not a new inconsistency. We’ve known about this since “open” was first proposed. > > > > > > > > > > > > Having sealed protocols would be nice, but it’s too late for Swift 3 IMO. > > > > > > > > > > Everything is too late for Swift 3. Bug fixes are about to be too late for Swift 3, much less any actual language changes. > > > > > > > > > > John. > > > > > > > > > > > Karl > > > > > > > > > > > > > On 22 Aug 2016, at 20:40, Adrian Zubarev via swift-evolution \ wrote: > > > > > > > > > > > > > > Hello dear Swift community, > > > > > > > > > > > > > > I was updating some of my libraries where I noticed that the new open access modifier made the public modifier inconsistent in one way. > > > > > > > > > > > > > > Conformances to protocols is logically the same as inheritances on classes. > > > > > > > > > > > > > >    • Conformances == (abstract) inheritance > > > > > > > That said we should allow protocols to be open/public like we now allow this distinction for classes. > > > > > > > > > > > > > >    • open protocol from module A should mean that I’m allowed to conform to it in module B > > > > > > >    • public protocol will act as an interface in module B > > > > > > > Not only sounds this behavior like ‘nice to have’, it’s inconsistency and it’s a ‘really need’ + a source breaking change in general. > > > > > > > > > > > > > > A common mistake in Swift 3.0 would be to hide protocol members behind public modifier for protocols that meant to be open. If a protocol member in an open class is disallowed to be overridden by the public modifier and this behavior is fixed, that will imply that you’ll have to open the member which you intended to be not overridable. > > > > > > > > > > > > > > // Before: > > > > > > > > > > > > > > // In module A > > > > > > > public protocol Proto { > > > > > > > func doSomething() > > > > > > > } > > > > > > > > > > > > > > open class Base : Proto { > > > > > > > // Dissallow to override - this would be a common mistake > > > > > > > public func doSomething() {} > > > > > > > } > > > > > > > > > > > > > > // Used in module B - so it should be `open` after all > > > > > > > class Test : Proto { > > > > > > > func doSomething() {} > > > > > > > } > > > > > > > > > > > > > > // After: > > > > > > > // In module A > > > > > > > open protocol Proto { > > > > > > > func doSomething() > > > > > > > } > > > > > > > > > > > > > > open class Base : Proto { > > > > > > > // Whops we have to grant the ability to override this method now > > > > > > > // I made a mistake designing my protocol in Swift 3.0 :/ > > > > > > > open func doSomething() {} > > > > > > > } > > > > > > > > > > > > > > // In module B > > > > > > > class Test2 : Base { > > > > > > > // Uuuuuuh I can do bad things with this now if the module A was not redesigned to fix this. :))) > > > > > > > override func doSomething() {} > > > > > > > } > > > > > > > > > > > > > > Personally I don’t have any feeling of how huge the impact might be on Swift if this behavior will be fixed. I also cannot tell if it’s something for Swift 3.x or Swift 4.0. > > > > > > > > > > > > > > -- > > > > > > > Adrian Zubarev > > > > > > > Sent with Airmail > > > > > > > > > > > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > > > > > > swift-evolution mailing list > > > > > > > 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](https://lists.swift.org/mailman/listinfo/swift-evolution) > > > > > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > > > swift-evolution mailing list > > > > 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](https://lists.swift.org/mailman/listinfo/swift-evolution) ---
**Author:** ![Chris\_Lattner](https://avatars.discourse-cdn.com/v4/letter/c/bc8723/32.png) [@Chris\_Lattner](https://forums.swift.org/u/Chris_Lattner)\ **Post date:** [October 7, 2016, 6:18pm UTC](https://forums.swift.org/t/late-pitch-open-public-protocols/3834/11 "2016-10-07T18:18:16Z")
We haven’t planned what Swift 4 phase 2 will be, but I am pretty sure that important model changes will always be considered. That said, reopening this discussion only makes sense if there is no insight or information. “fileprivate” and “open” were both \*extensively\* discussed when the decision was made, I don’t think they were “rushed”. -Chris > **···** > > > On Oct 7, 2016, at 11:05 AM, Goffredo Marocchi via swift-evolution \ wrote: > > > > True too, but dust settling will mean that for each speck the justification burden will rise quite massively. Not fixing this for Swift 4 phase 1 may mean a breaking change very very hard to justify for Swift 4 phase 2 which is for additive changes IIRC and even harder for Swift 5 and harder again on Swift 6 unless I am missing the core team vision for Swift's evolution.