[swift-evolution] Static Dispatch Pitfalls

[Vladimir.S]

I support the opinion that Swift should somehow warn us that some type has 
the same method(exact matched or even if the same name?) as in protocol 
extension for the conformed protocol(if no such method is in protocol 
itself *or* if declared, but conformance to protocol was introduced in base 
class and base contains no implemntation for method with default 
implementation(see my another email with example in this thread) - in both 
cases it will be statically dispatched)

But I don't think `final` keyword will help there as it can't help if we 
initially have protocol and extension in 3rd party code, and wants to 
conforms our(or even not our) class with *existed* methods to that protocol 
via type extension. So, we just can't/don't want/have no rights to change 
anything in protocol/extension and probably in the type.

So, the only solution I can see here -
1) warning from Swift compiler if method in type just shadowing default 
implementation in protocol and such protocol's mehtod will be dispatched 
statically(in any of two possible situation of static dispatch)
2) *plus* some posibility to 'fix' this warning. I see two options here:
some @warn_nondynamic(OurType.someMethod)
which will say to compiler "I know that OurType.someMethod is the same as 
protocol extension method that will be dispatched statically"
or
some extended decorations in type itself or in *type extension*:
extension OurType {
   nondynamicwarn func someMethod(); // probably ; required here
}

On 21.05.2016 23:16, Brent Royal-Gordon via swift-evolution wrote:
> I *did* propose forcing them final, and I'm still very skeptical that a
> `nondynamic` keyword that does nothing when you shadow the method is a
> good idea. People are still going to naïvely try to override these
> methods and be surprised when it doesn't work. A `nondynamic` keyword at
> the original declaration site will help them understand what happened
> when they're investigating the bug, but it still seems like this kind of
> code is so suspect that Swift ought to flag it from the start.