I still think that the type of the reference governs which code runs feels so vestigial of a part of C++ I always disliked (default if you are not using the virtual keyword). Especially dealing with protocols that have generally always be interpreted to be abstract API contracts.
I would say to have dynamic dispatching to be default unless the compiler knows there is no sideffect (no difference if an instance is referred through a certain reference type or another) or the used specified a a keyword in the public protocol interface. [[iOS messageWithData:ideas] broadcast] > On 27 Apr 2016, at 21:17, Tod Cunningham via swift-evolution > <[email protected]> wrote: > > 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 _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
