[swift-evolution] Proposal: Split extensions into implementing methods and adding static functions Was: [swift-evolution-announce] [Review] SE-0164: Remove final support in protocol extensions

[Brent Royal-Gordon]

> On Apr 13, 2017, at 3:10 PM, Howard Lovatt via swift-evolution <swift-evolution at swift.org> wrote:
> 
> I don't see that retroactive conformance needs to be exportable. If it is exported then you cannot prevent clashes from two modules, this is a known problem in C#. Because of this and other problems with C# extensions, this style of extension were rejected by other language communities (notably Java and Scala). 
> 
> A better alternative for export is a new class that encapsulates the standard type but with added methods for the protocol to be added. This way there is no clash between modules. EG:
> 
>     public protocol P {
>         func m() -> String
>     }
>     public class PInt: P {
>         var value = 0
>         func m() -> String { return "PI.m" }
>     }

Howard, this would be very source-breaking and would fail to achieve fundamental goals of Swift's protocol design. Removing retroactive conformance is no more realistic than removing Objective-C bridging—another feature which introduces various ugly edge cases and tricky behaviors but is also non-negotiable.

-- 
Brent Royal-Gordon
Architechies