[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 > <[email protected]> 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
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
