[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

[Jakub Suder]

Thanks for the explanation Adrian, I also had to Google this :)

Personally I'd love some kind of solution that would prevent this confusion
of why this method does different things when called on the same object in
two different ways, but I don't have any ideas how this could be solved...
It's something that most people learning Swift definitely won't expect to
work as it works now (unless they're coming from a language that mostly
works with static dispatch, but I'm guessing most people won't).


On 11 April 2017 at 15:50, Adrian Zubarev via swift-evolution <
swift-evolution at swift.org> wrote:

> 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.
>
>
> _______________________________________________
> 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/20170412/6565a92a/attachment.html>