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
> <swift-evolution@swift.org> 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 <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
