[swift-evolution] Proposal: Split extensions into implementing methods and adding static functions Was: [swift-evolution-announce] [Review] SE-0164: Remove final support in protocol extensions

Adrian Zubarev adrian.zubarev at devandartist.com
Tue Apr 11 08:50:40 CDT 2017

I myself pitched that requirement quite a few times on the list. Thank you, finally I understood why it’s not possible. Now I fully agree that the requirement of an override should not exist for the base type conforming to the protocol.

For those who might misunderstand the concept of retroactive conformances just like I did it, here is a quick snippet for you.

Imagine you’re working on some iOS project and for some reason you need an existential that only knows a property title of type String?.

protocol P { var title: String? { get set } }
Now you could retroactively conform types that already have this property to that protocol P without the need of implementing the property yourself. Think of it as a backdoor. ;)

extension UIViewController : P {} // This just works
The proposed solution will simply break this nice feature.

Adrian Zubarev
Sent with Airmail

Am 11. April 2017 um 00:52:01, Xiaodi Wu via swift-evolution (swift-evolution at swift.org) schrieb:

Requiring `override` breaks retroactive conformance of types to protocols. This idea has been brought up over half a dozen times. Each time it fails in not being able to accommodate retroactive conformance.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170411/b16482af/attachment.html>

More information about the swift-evolution mailing list