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

T.J. Usiyan griotspeak at gmail.com
Wed Dec 9 04:57:41 CST 2015


I did not mean that but I can sort of see how you came to that. My intent
was that `final func doIt()` is a statement that `Foo.doIt()` is provided
in the same module but is not dynamic. It would be the same as what
currently happens when a method is not in a protocol but a default
implementation is provided.

On Wed, Dec 9, 2015 at 4:00 PM, Gwendal Roué <gwendal.roue at gmail.com> wrote:

>
> > Le 9 déc. 2015 à 11:22, T.J. Usiyan <griotspeak at gmail.com> a écrit :
> >
> > 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
>
> In this particular example, do you mean that a class that implements Foo
> would have to declare its own doIt() as final, and can not implement its
> own doThat() ?
>
>     class C : Foo {
>         final func doIt() -> String { … }    // final required
>         final func doThat() { … }    // illegal
>     }
>
> Gwendal
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151209/b1781bbe/attachment.html>


More information about the swift-evolution mailing list