[swift-evolution] Static Dispatch Pitfalls

[L Mihalkovic]

I posted a small playground with a few of the identified use cases 

	https://github.com/lmihalkovic/swift-lang

I also wrote somewhat of a summary of the current behavior (with what might cause trouble) and a summary of a few of the proposed remedies:

	https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160516/018560.html



> On May 22, 2016, at 8:03 AM, Vladimir.S via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 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
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution