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@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@swift.org <mailto:swift-evolution@swift.org>) schrieb:
>
>>
>>
>> Sent from my iPad
>>
>> On Mar 9, 2017, at 2:23 AM, Slava Pestov via swift-evolution
>> <swift-evolution@swift.org <mailto:swift-evolution@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@swift.org <mailto: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://gist.github.com/KingOfBrian/6f20c566114ac0ef54c8092d80e54ee7>
>>>> https://bugs.swift.org/browse/SR-1762
>>>> <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 <mailto:swift-evolution@swift.org>
>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>>
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution
> <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
