[swift-evolution] [swift-evolution-announce] [Review] SE-0164: Remove final support in protocol extensions

[Jordan Rose]

[Proposal: https://github.com/apple/swift-evolution/blob/master/proposals/0164-remove-final-support-in-protocol-extensions.md <https://github.com/apple/swift-evolution/blob/master/proposals/0164-remove-final-support-in-protocol-extensions.md>]

> On Apr 5, 2017, at 16:15, Howard Lovatt via swift-evolution <swift-evolution at swift.org> wrote:
> 
> The review of SE-0164 "Remove final support in protocol extensions"
> 
>> What is your evaluation of the proposal?
> The present situation isn't great. People get confused about which method will called with protocol extensions. Seems like every week there is a variation on this confusion on Swift Users mailing list. Therefore something needs to be done. 
> 
> However I am not keen on this proposal since it makes behaviour inconsistent between methods in protocol extensions, classes, and structs. 
> 
> I think a better solution would be one of the following alternatives:
> 
>   1. Must use final and final means it cannot be overridden; or
>   2. If not final dispatches using a table like a class and if marked final cannot be overridden and if marked dynamic uses obj-c dispatching; or
>   3. Must be marked dynamic and uses obj-c dispatching. 
> 
> My preference would be option 2 but I think any of the three is superior to the present situation or the proposal. 

People have suggested all of these before, but none of them are obviously correct. It's true that we have a difference between extension members that satisfy requirements and those that don't, and that that confuses people. However, an extension-only member of one protocol can be used to satisfy the requirements of another protocol today, which is a tool for code reuse.

(I think we managed to convince everyone that it's just a bug that a protocol extension method that satisfies a requirement cannot be overridden in a subclass, so at least that isn't an issue on top of the rest of this.)

Oh, and we can't retroactively add members of a protocol extension to existing adopters, which is why protocol extension members cannot be @objc. There are limited circumstances where that would be safe, but that would be a separate proposal.

Jordan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170406/4b57d406/attachment.html>