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