[swift-evolution] Static Dispatch Pitfalls

[Vladimir.S]

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.