[swift-evolution] Proposal: Universal dynamic dispatch for method calls
ilya
ilya.nikokoshev at gmail.com
Mon Dec 7 16:31:49 CST 2015
On Tue, Dec 8, 2015 at 1:22 AM, Kevin Ballard <kevin at sb.org> wrote:
> On Mon, Dec 7, 2015, at 02:18 PM, ilya wrote:
>
>
>
> I wouldn't mind seeing something like the `dynamic` keyword to allow
> concrete types to override these protocol extension methods (although
>
>
> You currently allow it by declaring method to be part of protocol, which
> means that an entry for some method is reserved in the protocol witness
> table. This entry will be filled either by concrete method, if present, or
> by protocol default implementation.
>
>
> Sure, if you define the protocol yourself, and you want the method to be
> available for all instances of the protocol. My `dynamic` suggestion is
> meant to cover the cases of a) you didn't define the protocol yourself, but
> you want to define a method that can be overridden by any class that can
> see your protocol extension, or b) you want to define the method only for a
> subset of protocol implementations (e.g. with a `where` clause) but still
> want to allow for overriding.
>
Interesting. I think your use case a) could work like this
protocol PP1 :P1 {
func overrideable() -> Int
}
extension P1 :PP1 { // doesn't currently compile with :PP1 inheritance
clause
func overrideable() -> Int {
return 1
}
}
extension C1 {
func overrideable() -> Int {
return 0
}
}
(C1() as P1).overrideable()
> That said, I think `dynamic` is the wrong keyword here, because it means
> runtime dynamic dispatch, and what I'm really talking about is just the
> ability to have a separate protocol witness table for the extension.
>
> -Kevin Ballard
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151208/6dd386c3/attachment.html>
More information about the swift-evolution
mailing list