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
> <[email protected]> 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
> [email protected]
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
