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

Thu Mar 9 10:41:45 CST 2017

+1 for the fix. Solid and straightforward.

On Thu, Mar 9, 2017 at 9:32 AM, Rod Brown via swift-evolution <
swift-evolution at swift.org> wrote:

> There has been a lot of discussion around this design decision.
> Personally, I’m with you: this should be allowed. Protocol extensions
> should be defaults, nothing more.
>
> The rationale mentioned in Swift Evolution for discouraging this behaviour
> tends to be that if you conform to the protocol, you should conform and
> adhere to all its extensions as well, and that not doing so in the same way
> will be inconsistent.
>
> I personally think this comes to the Type-first vs Protocol-first approach
> and I think instances of types should have the final say in the behaviour
> of the operation. While this would perform slightly worse, and could
> potentially be unsafe, I think it is consistent with the fact that not all
> implementers of a protocol behave exactly the same; indeed, if they did,
> we’d only have one type per protocol, in which case, what is the point of a
> protocol at all? Just do it with types.
>
> I love POP and protocol extensions but I’m tempered by the fact that not
> all types implement protocols in the same ways, and we can’t predict ahead
> of time where those differences will be needed.
>
>
> On 10 Mar 2017, at 12:48 am, Adrian Zubarev via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> My question is why cannot the Base type override the default
> implementation? I might want to override it, by calling the default
> implementation and modifying the result for my needs.
>
> Something like that:
>
> protocol P {
>     func foo() -> Int
> }
>
> extension P {
>     func foo() -> Int {
>         return 42
>     }
> }
>
> class Base : P {
>     override func foo() -> {
>
>         return default.foo() * 100
>     }
> }
>
> The example is kept simple.
>
>
>
> --
> Adrian Zubarev
> Sent with Airmail
>
> Am 9. März 2017 um 14:37:08, Matthew Johnson via swift-evolution (
> swift-evolution at swift.org) schrieb:
>
>
>
> Sent from my iPad
>
> On Mar 9, 2017, at 2:23 AM, Slava Pestov via swift-evolution <
> swift-evolution at swift.org> 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.
>
>
> Would this allow the override to call `Proto.f` through super?
>
>
> 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
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
> _______________________________________________
> 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/469df309/attachment.html>