I support *at least* to introduce such a special marker for method declared
*only* in protocol extension (no declaration for it in protocol itself) to
make it clear that it will be dispatched statically.
Probably right now I support `nondynamic`.
But, there is question regarding another situation when the protocol method
dispatched *statically* even if *defined* in protocol declaration:
protocol A {
func f()
func x()
}
extension A {
func x() {print("a-x")}
}
class B: A { // already strange. B depends on A extension. did not
implement all required methods from A
func f() {}
}
class C: B {
func x(){print("c-x")}
}
var c : A = C()
c.x() // "a-x". but C() *implements* x() that *is* defined in protocol
IMO this is totally unexpected and must be dispatched dynamically. I
believe that there can not be any explanation why this is correct: A - is a
protocol, C - is a class conformed to A protocol and implemented all
methods of that protocol.
It is clear, that you don't want to decorate A.x() with such `nondynamic`
as if it was implemented in B - it will be dynamic:
class B: A {
func f() {}
func x(){print("b-x")}
}
var b : A = B()
b.x() // "b-x". now dynamic
So, again, IMO at least we need to decorate protocol extension methods
that was not defined in protocol itself, but the 'issue' is bigger 'than
just this.
On 21.05.2016 16:27, Matthew Johnson via swift-evolution wrote:
Nobody is talking about forcing them final. We are talking about
annotating them with a keyword that documents their behavior (which is
unintuitive for sure but makes sense when you think through how things
work behind the scenes).
Maybe we will figure out a way to have something better in the future,
but until then highlighting the behavior via annotation is a pretty good
option.
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
