[swift-evolution] Proposal: Universal dynamic dispatch for method calls
T.J. Usiyan
griotspeak at gmail.com
Wed Dec 9 04:22:14 CST 2015
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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151209/9ca21a66/attachment.html>
More information about the swift-evolution
mailing list