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

[thorsten at portableinnovations.de]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151209/19281ff6/attachment.html>