[swift-evolution] [Draft] Remove support for final in protocol extensions

[Brian King]

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 <spestov at apple.com> 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 <
> swift-evolution at 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 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/20170309/8988f23f/attachment.html>