+1 Main part of proposal: Not sure that you need the required keyword, overload alone has proven sufficient in Java for the same feature.
Related features: For calling default implementations in inherited protocols I think this is a valuable feature but should be a seperate thread. On Thursday, 28 April 2016, Erica Sadun via swift-evolution < [email protected]> wrote: > 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 > -- -- Howard.
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
