>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
