It makes sense since protocol do not allow final. It doesn't make much sense to allow the extensions to be exempt from this.
Classes that inherit from it can still provide their own implementation of the supposed "final" protocol method which is contradictory to what final means. Protocol extensions should not allow final since the protocol definition doesn't allow it either. On Tue, Mar 7, 2017 at 10:23 PM Brian King via swift-evolution < swift-evolution@swift.org> wrote: > Hey Folks, This draft proposal addresses starter bug SR-1762. I believe > this is in scope for Swift 4 since it impacts source compatibility. It's > not a very exciting proposal, but I think it will help make Swift a little > more consistent. > > https://gist.github.com/KingOfBrian/6f20c566114ac0ef54c8092d80e54ee7 > https://bugs.swift.org/browse/SR-1762 > > Thanks > > Brian > Introduction > > This proposal suggests removing support for the final keyword when > declaring a function in a protocol extension. The presence of the final > keyword > does not currently generate an error message, and it does not actually > modify the dispatch behavior in any way. > > <https://gist.github.com/KingOfBrian/6f20c566114ac0ef54c8092d80e54ee7#motivation> > Motivation > > In the original protocol model of Swift, a developer could use the final > keyword > when declaring a function in a protocol extension to ensure the function > could not be overridden. This keyword has no use in Swift's current > protocol model, since functions in protocol extensions can not be > overridden and will always use direct dispatch. > > <https://gist.github.com/KingOfBrian/6f20c566114ac0ef54c8092d80e54ee7#detailed-design>Detailed > design > > The compiler should generate an error or warning when the final keyword > is used on a function declaration inside of a protocol extension. This is > consistent with the use of final in structs and enumerations. > > <https://gist.github.com/KingOfBrian/6f20c566114ac0ef54c8092d80e54ee7#source-compatibility>Source > compatibility > > This change will impact source compatibility. To maintain compatibility > with Swift 3, a warning will be generated in Swift 3 mode instead of an > error message. > > <https://gist.github.com/KingOfBrian/6f20c566114ac0ef54c8092d80e54ee7#effect-on-abi-stability>Effect > on ABI stability > > This has no effect on ABI stability > > <https://gist.github.com/KingOfBrian/6f20c566114ac0ef54c8092d80e54ee7#effect-on-api-resilience>Effect > on API resilience > > This has no effect on API resilience > > <https://gist.github.com/KingOfBrian/6f20c566114ac0ef54c8092d80e54ee7#alternatives-considered>Alternatives > considered > > The only alternative would be to not fix this bug > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
