Having to specify override to override the implementation of protocol leads one
further down the path that the protocol’s implementation is actually being
overridden. However, currently that is not the case. If the protocol’s
definition was actually being overridden, I think you would have a good case.
But swift, as it exists today, will still call the protocol’s default
implementation if accessed through the protocol type. So it isn’t really
overriding the implementation of the protocol:
For example:
protocol Test {
}
extension Test {
var hello: String {
return "hello"
}
}
class A: Test {
}
class B: Test {
var hello: String {
return "see ya"
}
}
print( A().hello ) // hello
print( B().hello ) // see ya
let test1: Test = A()
print( test1.hello ) // hello
let test2: Test = B()
print( test2.hello ) // hello <== not "see ya"
Thanks,
Tod Cunningham
From:
<[email protected]<mailto:[email protected]>>
on behalf of Erica Sadun via swift-evolution
<[email protected]<mailto:[email protected]>>
Reply-To: Erica Sadun <[email protected]<mailto:[email protected]>>
Date: Wednesday, April 27, 2016 at 1:10 PM
To: swift-evolution
<[email protected]<mailto:[email protected]>>, Jordan Rose
<[email protected]<mailto:[email protected]>>, Douglas Gregor
<[email protected]<mailto:[email protected]>>
Subject: [swift-evolution] [Pitch] Requiring proactive overrides for default
protocol implementations.
From the Swift Programming Language: Methods on a subclass that override the
superclass’s implementation are marked with override—overriding a method by
accident, without override, is detected by the compiler as an error. The
compiler also detects methods with override that don’t actually override any
method in the superclass.
I would like to extend this cautious approach to protocols, forcing the
developer to deliberately override an implementation that’s inherited from a
protocol extension. This would prevent accidental overrides and force the user
to proactively choose to implement a version of a protocol member that already
exists in the protocol extension.
I envision this as using the same `override` keyword that’s used in class based
inheritance but extend it to protocol inheritance:
protocol A {
func foo()
}
extension A {
func foo() { .. default implementation … }
}
type B: A {
override required func foo () { … overrides implementation … }
}
I’d also like to bring up two related topics, although they probably should at
some point move to their own thread if they have any legs:
Related topic 1: How should a consumer handle a situation where two unrelated
protocols both require the same member and offer different default
implementations. Can they specify which implementation to accept or somehow run
both?
type B: A, C {
override required func foo() { A.foo(); C.foo() }
}
Related topic 2: How can a consumer “inherit” the behavior of the default
implementation (like calling super.foo() in classes) and then extend that
behavior further. This is a bit similar to how the initialization chaining
works. I’d like to be able to call A.foo() and then add custom follow-on
behavior rather than entirely replacing the behavior.
type B: A {
override required func foo() { A.foo(); … my custom behavior … }
}
cc’ing in Jordan who suggested a new thread on this and Doug, who has already
expressed some objections so I want him to have the opportunity to bring that
discussion here.
— E
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
