[swift-evolution] [Pitch] Requiring proactive overrides for default protocol implementations.

[Howard Lovatt]

+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 <
swift-evolution at swift.org> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160429/4b62bb47/attachment.html>