[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