[swift-evolution] Proposal: Universal dynamic dispatch for method calls

[Kevin Ballard]

Any thoughts on instead having to mark the default method
implementations as `default`?

It still seems strange to me to consider a protocol extension that uses
the `final` keyword, because a) protocols have nothing to do with
classes and `final` means no subclassing, and b) methods defined in
protocol extensions by definition can't be overridden already, so the
`final` keyword is just sort of like saying "no really, I mean it, you
can't do the thing you already can't do!". But since I see the value in
making it clear which methods are default implementations (and thus can
be overridden), and which are actually just new methods, I'm in favor of
using the `default` keyword on the former:

protocol Foo {    func foo() -> String }

extension Foo {    default func foo() -> String { return "foo!" }
func bar() -> String { return "bar" } }

-Kevin

On Wed, Dec 9, 2015, at 09:37 AM, thorsten--- via swift-evolution wrote:
>
> This won't work if the protocol is provided by someone else (meaning I
> can't change its source code) and I want to provide a protocol
> extension in my own module.
>
> I like the original idea of having to mark extension methods not in
> the protocol definition as final. This would make the semantics much
> clearer.
>
> -Thorsten
>
> Am 09.12.2015 um 11:22 schrieb T.J. Usiyan via swift-evolution <swift-
> evolution at swift.org>:
>> I actually suggest something along the lines of
>>
>> protocol Foo {        final func doIt() -> String    }
>>
>> extension Foo {        final func doIt() -> String {
>> print("I did it.")        }        final func doThat() {
>> print("I did that.")        }    }
>>
>> to indicate that foo will be provided in this module and is not ever
>> to be dynamically dispatched. This draws attention to the fact that
>> dispatch is static in a clear consistent manner.
>>
>> TJ
>>
>> On Wed, Dec 9, 2015 at 1:31 PM, Gwendal Roué <swift-
>> evolution at swift.org> wrote:
>>>
>>>
> Le 9 déc. 2015 à 06:31, Paul Cantrell <cantrell at pobox.com> a écrit :
>>>
>
>>>
> Gwendal Roué wrote:
>>>
>> Whatever the direction this proposal is aiming at, please remember
>> that it is desirable for some APIs to let adopting types "override"
>> the default implementation provided by protocols.
>>>
>
>>>
>
>>>
> I would certainly hope nobody is proposing changing that! Once a
> method is virtually dispatched, it should be virtual all the way down
> to the implementing type.
>>>
>>> Yes, and it’s why I’m concerned. When a protocol provides a default
>>> implementation, how will an adopting type invoke that default
>>> implementation in its own implementation?
>>>
>>>
With classes, it’s easy: you call super.
>>>
>>>
With protocols, it’s much less easy, if possible at all, as soon as all
methods are dynamically dispatched.
>>>
>>>
Gwendal Roué
>>>
>>>
>>>
_______________________________________________
>>>
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/20151209/31e8260d/attachment.html>