I have a change ready and can turn it into a PR. Jordan mentioned in the bug that this would require a SE proposal, but looking at this as a bug in the current implementation rather than a change in the language makes sense. It certainly is trivial enough, and doesn't change any semantics, so I'll make a PR today.
If we do want a proposal to move forward Erica gave me some great language updates that I can address. The other bug https://bugs.swift.org/browse/SR-103 looks like it's been getting some attention and debate on if it should go through the evolution process. Brian On Thu, Mar 9, 2017 at 3:23 AM, Slava Pestov <[email protected]> wrote: > I think the fact that the type checker permits ‘final’ to appear inside > protocol extensions is an oversight and this probably does not even warrant > a proposal. I don’t think allowing this was ever part of the conceptual > model of protocol extensions at any point in time (if you recall they were > introduced ‘recently’, in Swift 2). If someone put together a PR which > makes ‘final’ in protocol extensions an error in Swift 4 mode (and a > warning in 3), I would merge it. > > FWIW that there is one restriction around the direct dispatch here we want > to lift, but it’s not related to this proposal. > > If you have a base class conforming to a protocol using default > requirements, eg > > protocol Proto { func f() } > extension Proto { func f() { } } > > class Base : Proto {} > > Currently the witness table for Base : Proto directly references the > extension method Proto.f. > > We want to allow this, at least inside the module: > > class Derived { > override func f() {} // does not work currently > } > > This will mean that ‘Proto.f’ will appear in the vtable of ‘Base’, > pointing at the extension method. The conformance will dispatch through the > vtable instead of directly calling the extension method. > > Slava > > On Mar 7, 2017, at 7:23 PM, Brian King via swift-evolution < > [email protected]> 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 > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution > > >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
