[swift-evolution] Overriding protocol default implementation

[Adrian Zubarev]

I’d be in favor if we could look at this topic further - Generics Manifesto: Allowing subclasses to override requirements satisfied by defaults.

In my world this should look like this:

protocol P {
  func foo()
}

extension P {
  func foo() { print("P") }
}

class C : P {
  // gets the protocol extension's
   
  // or override it
  override func foo() {
     
    // do your work or optionally call the default implementation
    default.foo() // Notice how `default` suits here better than `super`
  }
}

class D : C {
     
  override func foo() {  
     
    // #1 - if `C` has not overridden `foo()`
    print("D")  
    // or
    default.foo()
     
    // #2 - if `C` has overridden `foo()`
    print("D") // ignore everything
    // or call `super`
    super.foo()
    // or even `default`
    default.foo()  
  }
}
C does not necessarily need to be a class, that should be the same behavior for value types as well.

Additional to that we could make default implementations final so that you cannot override them from the conforming type at all.

Having this much of power and flexibility would be simply great.

Plus the mentioned behavior from the current thread should not even exist IMO.



-- 
Adrian Zubarev
Sent with Airmail

Am 10. Februar 2017 um 21:29:46, Anton Zhilin via swift-evolution (swift-evolution at swift.org) schrieb:

I’d even suggest to force  
final for such methods:

protocol Fooable { }

extension Fooable {
//  func foo() { }        // error: must be declared as final
    final func foo() { }  // ok
}
_______________________________________________
swift-evolution mailing list
swift-evolution at swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170210/39695c9b/attachment.html>