Shall we revive this discussion?
--
Adrian Zubarev
Sent with Airmail
Am 25. August 2016 um 19:29:13, John McCall (rjmcc...@apple.com) schrieb:
On Aug 25, 2016, at 2:29 AM, Karl via swift-evolution
<swift-evolution@swift.org> 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
<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
https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
