# Mark protocol methods with their protocol

**URL:** <https://forums.swift.org/t/mark-protocol-methods-with-their-protocol/4034>\
**Category:** Discussion\
**Created:** [September 16, 2016, 3:29pm UTC](https://forums.swift.org/t/mark-protocol-methods-with-their-protocol/4034 "2016-09-16T15:29:21Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![davbeck](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/davbeck/32/32237_2.png) [@davbeck](https://forums.swift.org/u/davbeck)\
**Post date:** [September 16, 2016, 3:29pm UTC](https://forums.swift.org/t/mark-protocol-methods-with-their-protocol/4034/1 "2016-09-16T15:29:21Z")

</div>

With the transition from Swift 2 -\> 3 I’ve started running into one particular issue VERY often (although it’s not necessarily specific to the transition). If a protocol method is optional (either because it is an @objc optional or because it has a default implementation) there is a risk that the conformer will have a misspelled or slightly incorrectly typed implementation of the method. For instance:

protocol RouteDestinationViewController: class {  
&nbsp;&nbsp;static func viewController(with url: URL, properties: [String:String]) -\> UIViewController?  
}

extension RouteDestinationViewController where Self: UIViewController {  
&nbsp;&nbsp;static func viewController(with url: URL, properties: [String:String]) -\> UIViewController? {  
&nbsp;&nbsp;&nbsp;&nbsp;return Self.init()  
&nbsp;&nbsp;}  
}

class FooController: UIViewController, RouteDestinationViewController {  
&nbsp;&nbsp;static func viewController(with url: URL, properties: [String:Any]) -\> UIViewController? {  
&nbsp;&nbsp;&nbsp;&nbsp;return FooController(properties: properties)  
&nbsp;&nbsp;}  
}

Notice the issue there? Properties is supposed to be [String:String], but FooController uses [String:Any] (this is an exact issue I ran into after a small refactor). When viewController(with:properties:) is called, it will use the default implementation instead of what the compiler sees as a completely different method. Over the betas the compiler has gotten better warnings about this, but is still not 100%.

Other cases of this issue are common with imported ObjC protocols that have different naming in Swift. In some cases an @objc name must be applied to ensure it is declared in a way that the protocol can see it.

We solve this problem with subclassing by requiring “override”. If the override keyword is present but the superclass doesn’t have a matching method, the compiler warns us about it. Similarly if the superclass implements the same method and the subclass doesn’t include override, we get a warning so that it is clear that you are overriding behavior.

For protocols, I don’t think a required keyword would be the best approach. It’s a completely valid case that a type could conform to a protocol using existing methods, perhaps even from a different module. Further, a single method could satisfy multiple protocols, and be overriden from a superclass. What I would propose would be something like an optional override(\<#protocol name#\>). Something like the following:

&nbsp;&nbsp;override(RouteDestinationViewController) static func viewController(with url: URL, properties: [String:Any]) -\> UIViewController? {  
&nbsp;&nbsp;&nbsp;&nbsp;return FooController(properties: properties)  
&nbsp;&nbsp;}

A method should be able to include multiple overrides (including a bare override to indicate that it is overriding a class method).

Thoughts? Are you seeing similar issues?

David Beck  
[http://davidbeck.co](http://davidbeck.co)  
[http://twitter.com/davbeck](http://twitter.com/davbeck)

> **[Log into Facebook](https://www.facebook.com/davbeck)**
>
> Log into Facebook to start sharing and connecting with your friends, family, and people you know.

---

<div class="post-metadata">

**Author:** ![VladimirS](https://avatars.discourse-cdn.com/v4/letter/v/f9ae1b/32.png) [@VladimirS](https://forums.swift.org/u/VladimirS)\
**Post date:** [September 16, 2016, 6:44pm UTC](https://forums.swift.org/t/mark-protocol-methods-with-their-protocol/4034/2 "2016-09-16T18:44:24Z")

</div>

David, thank you for a real-word example when such feature will be very useful and can protect from hard-to-find bugs. IMO This shows that we should find a solution for the problem as soon as possible.

Such or similar question was discussed already in an number of threads, for example in "Requiring proactive overrides for default protocol implementations." and in "Requiring special keyword to mark protocol implementation methods", probably in other threads also.

The first is that `override` is not used in structs, so IMO it will be alien here.  
Second, if protocol has no default implementation for the method- would you require the `override(Protocol)` also?

Then, in case you will not require a keyword when no default implementation - you should think about retrospective adding of extension.

I.e. imagine, you have a source file, let's call it SomeClass.swift which you can't or don't want to change(this could be some complex source from 3rd party, from github, or from other developer of your company). This file compiles without problems. It contains:

public protocol Foo { func foo() }  
public class Some: Foo { func foo() {...} }

You added SomeClass.swift to your project and in your My.swift you added default implementation for Foo protocol:

extension Foo { func foo() {...} }

So, now, when you compile your project, there is default implementation for foo() and class Some should contains `override(Foo)`, but you can't change SomeClass.swift.

The only solution I see here, is if this `override(Foo)` will be optional, and just express developer's intention, if he/she wants this. I.e. it is not required, but if you specify it - compiler will check this intention.  
But AFAIR unfortunately someone from core team mentioned that they don't want such optional solution.

And, at the end, I do think the real reason of your problem is not that protocol method has default implementation, but that `viewController(with:properties:)` definition in `FooController` does not say for compiler(and compiler does not check this) that this method was defined \*exactly\* to confirm to protocol. I.e. you can't clearly express your intention regarding why this method is here. Check this example:

Let's assume you defined protocol Foo in FooProto.swift file:

public protocol Foo { func foo() }

and have class `Some` conformed to Foo in SomeClass.swift:

public class Some : Foo { func foo() {...} }

it is clear \*why\* foo is here..

OK, now, let's assume you changed Foo protocol in the way, that SomeClass.swift \*still\* compiles :

public protocol Foo { func bar() }  
extension Foo {  
&nbsp;&nbsp;&nbsp;func bar() {...}  
}

Now, SomeClass.swift still compiles but it contains \*wrong\* intention that foo() method is an implementation of protocol requirement. And this can lead to bugs/unexpected behavior.

I think what we do need a way to clearly shows intention that we defined some method \*exactly\* because the conformed protocol has it and to make compiler check this.

My favorite solution is 'implements' keyword inside class/struct to highlight that I defined this method as implementation for the protocol requirement. IMO solves a big percent of discussed issues with just one added keyword, that also will help with understanding the code when you read it.

Other solution that was mentioned by (as I remember) member of core team is treat class extension with protocol conformance as such intention, i.e. when you say  
extension Some: Foo {..}  
compiler will understand this as all methods inside such extension must 'belongs' to the Foo protocol, i.e. if there is some method that does not exist in Foo - it will raise an error. But in this case we need to require that each protocol conformance will be declared as extension, not inline in class definition. Personally I don't believe in this solution.

> **···**
>
> On 16.09.2016 18:29, David Beck via swift-evolution wrote:
> 
> > With the transition from Swift 2 -\> 3 I’ve started running into one  
> > particular issue VERY often (although it’s not necessarily specific to the  
> > transition). If a protocol method is optional (either because it is an  
> > @objc optional or because it has a default implementation) there is a risk  
> > that the conformer will have a misspelled or slightly incorrectly typed  
> > implementation of the method. For instance:
> > 
> > protocolRouteDestinationViewController: class{  
> > staticfuncviewController(with url: URL, properties: [String:String]) -\>  
> > UIViewController?  
> > }
> > 
> > extensionRouteDestinationViewControllerwhereSelf: UIViewController {  
> > staticfuncviewController(with url: URL, properties: [String:String]) -\>  
> > UIViewController? {  
> > returnSelf.init()  
> > }
> > 
> > classFooController: UIViewController, RouteDestinationViewController{  
> > staticfuncviewController(with url: URL, properties: [String:Any]) -\>  
> > UIViewController? {  
> > returnFooController(properties: properties)  
> > }
> > 
> > Notice the issue there? Properties is supposed to be [String:String], but  
> > FooController uses [String:Any] (this is an exact issue I ran into after a  
> > small refactor). When viewController(with:properties:) is called, it will  
> > use the default implementation instead of what the compiler sees as a  
> > completely different method. Over the betas the compiler has gotten better  
> > warnings about this, but is still not 100%.
> > 
> > Other cases of this issue are common with imported ObjC protocols that have  
> > different naming in Swift. In some cases an @objc name must be applied to  
> > ensure it is declared in a way that the protocol can see it.
> > 
> > We solve this problem with subclassing by requiring “override”. If the  
> > override keyword is present but the superclass doesn’t have a matching  
> > method, the compiler warns us about it. Similarly if the superclass  
> > implements the same method and the subclass doesn’t include override, we  
> > get a warning so that it is clear that you are overriding behavior.
> > 
> > For protocols, I don’t think a required keyword would be the best approach.  
> > It’s a completely valid case that a type could conform to a protocol using  
> > existing methods, perhaps even from a different module. Further, a single  
> > method could satisfy multiple protocols, and be overriden from a  
> > superclass. What I would propose would be something like an optional  
> > override(\<#protocol name#\>). Something like the following:
> > 
> > override(RouteDestinationViewController) staticfuncviewController(with url:  
> > URL, properties: [String:Any]) -\> UIViewController? {  
> > returnFooController(properties: properties)  
> > }
> > 
> > A method should be able to include multiple overrides (including a bare  
> > override to indicate that it is overriding a class method).
> > 
> > Thoughts? Are you seeing similar issues?
> > 
> > \*David Beck\*  
> > [http://davidbeck.co](http://davidbeck.co)  
> > [http://twitter.com/davbeck](http://twitter.com/davbeck)  
> > [David Beck](http://facebook.com/davbeck)
> > 
> > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_  
> > swift-evolution mailing list  
> > swift-evolution@swift.org  
> > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution)

---

<div class="post-metadata">

**Author:** ![DevAndArtist](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/devandartist/32/287_2.png) [@DevAndArtist](https://forums.swift.org/u/DevAndArtist)\
**Post date:** [September 16, 2016, 8:24pm UTC](https://forums.swift.org/t/mark-protocol-methods-with-their-protocol/4034/3 "2016-09-16T20:24:05Z")

</div>

I don’t really like the idea of override(ProtocolName), but I’d support the single override here. On value types it’s easier to recognize the member of a protocol which had a default implementation.

I don’t feel like adding override to all members that replaces some default implementation will break anything. Furthermore, I’d love to see the addition where we could call the default implementation.

Here is some bikeshedding:

protocol A {}

extension A {  
&nbsp;&nbsp;&nbsp;func foo() { .. }  
}

protocol B : A {}

extension B {  
&nbsp;&nbsp;&nbsp;// overriding default implementation from an other one!?  
&nbsp;&nbsp;&nbsp;override func foo() {  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;// call default implementation of A  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;default.foo()  
&nbsp;&nbsp;&nbsp;&nbsp;}  
}

struct C : A {  
&nbsp;&nbsp;&nbsp;// overriding some default implementation  
&nbsp;&nbsp;&nbsp;override func foo() {  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;// call default implementation  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;default.foo()  
&nbsp;&nbsp;&nbsp;&nbsp;}  
}

struct D : B {  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;// overriding some default implementation  
&nbsp;&nbsp;&nbsp;override func foo() {  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;// call default implementation B  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;// which will also call default implementation of A  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;default.foo()  
&nbsp;&nbsp;&nbsp;&nbsp;}  
}

> **···**
>
> --  
> Adrian Zubarev  
> Sent with Airmail
> 
> Am 16. September 2016 um 20:45:05, Vladimir.S via swift-evolution (swift-evolution@swift.org) schrieb:
> 
> David, thank you for a real-word example when such feature will be very  
> useful and can protect from hard-to-find bugs. IMO This shows that we  
> should find a solution for the problem as soon as possible.
> 
> Such or similar question was discussed already in an number of threads, for  
> example in "Requiring proactive overrides for default protocol  
> implementations." and in "Requiring special keyword to mark protocol  
> implementation methods", probably in other threads also.
> 
> The first is that `override` is not used in structs, so IMO it will be  
> alien here.  
> Second, if protocol has no default implementation for the method- would you  
> require the `override(Protocol)` also?
> 
> Then, in case you will not require a keyword when no default implementation  
> - you should think about retrospective adding of extension.
> 
> I.e. imagine, you have a source file, let's call it SomeClass.swift which  
> you can't or don't want to change(this could be some complex source from  
> 3rd party, from github, or from other developer of your company). This file  
> compiles without problems. It contains:
> 
> public protocol Foo { func foo() }  
> public class Some: Foo { func foo() {...} }
> 
> You added SomeClass.swift to your project and in your My.swift you added  
> default implementation for Foo protocol:
> 
> extension Foo { func foo() {...} }
> 
> So, now, when you compile your project, there is default implementation for  
> foo() and class Some should contains `override(Foo)`, but you can't change  
> SomeClass.swift.
> 
> The only solution I see here, is if this `override(Foo)` will be optional,  
> and just express developer's intention, if he/she wants this. I.e. it is  
> not required, but if you specify it - compiler will check this intention.  
> But AFAIR unfortunately someone from core team mentioned that they don't  
> want such optional solution.
> 
> And, at the end, I do think the real reason of your problem is not that  
> protocol method has default implementation, but that  
> `viewController(with:properties:)` definition in `FooController` does not  
> say for compiler(and compiler does not check this) that this method was  
> defined \*exactly\* to confirm to protocol. I.e. you can't clearly express  
> your intention regarding why this method is here. Check this example:
> 
> Let's assume you defined protocol Foo in FooProto.swift file:
> 
> public protocol Foo { func foo() }
> 
> and have class `Some` conformed to Foo in SomeClass.swift:
> 
> public class Some : Foo { func foo() {...} }
> 
> it is clear \*why\* foo is here..
> 
> OK, now, let's assume you changed Foo protocol in the way, that  
> SomeClass.swift \*still\* compiles :
> 
> public protocol Foo { func bar() }  
> extension Foo {  
> func bar() {...}  
> }
> 
> Now, SomeClass.swift still compiles but it contains \*wrong\* intention that  
> foo() method is an implementation of protocol requirement. And this can  
> lead to bugs/unexpected behavior.
> 
> I think what we do need a way to clearly shows intention that we defined  
> some method \*exactly\* because the conformed protocol has it and to make  
> compiler check this.
> 
> My favorite solution is 'implements' keyword inside class/struct to  
> highlight that I defined this method as implementation for the protocol  
> requirement. IMO solves a big percent of discussed issues with just one  
> added keyword, that also will help with understanding the code when you  
> read it.
> 
> Other solution that was mentioned by (as I remember) member of core team is  
> treat class extension with protocol conformance as such intention, i.e.  
> when you say  
> extension Some: Foo {..}  
> compiler will understand this as all methods inside such extension must  
> 'belongs' to the Foo protocol, i.e. if there is some method that does not  
> exist in Foo - it will raise an error. But in this case we need to require  
> that each protocol conformance will be declared as extension, not inline in  
> class definition. Personally I don't believe in this solution.
> 
> On 16.09.2016 18:29, David Beck via swift-evolution wrote:
> 
> > With the transition from Swift 2 -\> 3 IБ─≥ve started running into one  
> > particular issue VERY often (although itБ─≥s not necessarily specific to the  
> > transition). If a protocol method is optional (either because it is an  
> > @objc optional or because it has a default implementation) there is a risk  
> > that the conformer will have a misspelled or slightly incorrectly typed  
> > implementation of the method. For instance:
> > 
> > protocolRouteDestinationViewController: class{  
> > staticfuncviewController(with url: URL, properties: [String:String]) -\>  
> > UIViewController?  
> > }
> > 
> > extensionRouteDestinationViewControllerwhereSelf: UIViewController {  
> > staticfuncviewController(with url: URL, properties: [String:String]) -\>  
> > UIViewController? {  
> > returnSelf.init()  
> > }  
> > }
> > 
> > classFooController: UIViewController, RouteDestinationViewController{  
> > staticfuncviewController(with url: URL, properties: [String:Any]) -\>  
> > UIViewController? {  
> > returnFooController(properties: properties)  
> > }  
> > }
> > 
> > Notice the issue there? Properties is supposed to be [String:String], but  
> > FooController uses [String:Any] (this is an exact issue I ran into after a  
> > small refactor). When viewController(with:properties:) is called, it will  
> > use the default implementation instead of what the compiler sees as a  
> > completely different method. Over the betas the compiler has gotten better  
> > warnings about this, but is still not 100%.
> > 
> > Other cases of this issue are common with imported ObjC protocols that have  
> > different naming in Swift. In some cases an @objc name must be applied to  
> > ensure it is declared in a way that the protocol can see it.
> > 
> > We solve this problem with subclassing by requiring Б─°overrideБ─². If the  
> > override keyword is present but the superclass doesnБ─≥t have a matching  
> > method, the compiler warns us about it. Similarly if the superclass  
> > implements the same method and the subclass doesnБ─≥t include override, we  
> > get a warning so that it is clear that you are overriding behavior.
> > 
> > For protocols, I donБ─≥t think a required keyword would be the best approach.  
> > ItБ─≥s a completely valid case that a type could conform to a protocol using  
> > existing methods, perhaps even from a different module. Further, a single  
> > method could satisfy multiple protocols, and be overriden from a  
> > superclass. What I would propose would be something like an optional  
> > override(\<#protocol name#\>). Something like the following:
> > 
> > override(RouteDestinationViewController) staticfuncviewController(with url:  
> > URL, properties: [String:Any]) -\> UIViewController? {  
> > returnFooController(properties: properties)  
> > }
> > 
> > A method should be able to include multiple overrides (including a bare  
> > override to indicate that it is overriding a class method).
> > 
> > Thoughts? Are you seeing similar issues?
> > 
> > \*David Beck\*  
> > [http://davidbeck.co](http://davidbeck.co)  
> > [http://twitter.com/davbeck](http://twitter.com/davbeck)  
> > [David Beck](http://facebook.com/davbeck)
> > 
> > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_  
> > swift-evolution mailing list  
> > swift-evolution@swift.org  
> > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution)
> 
> \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_  
> swift-evolution mailing list  
> swift-evolution@swift.org  
> [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution)

---

<div class="post-metadata">

**Author:** ![Charles\_Srstka](https://avatars.discourse-cdn.com/v4/letter/c/0ea827/32.png) [@Charles\_Srstka](https://forums.swift.org/u/Charles_Srstka)\
**Post date:** [September 16, 2016, 9:59pm UTC](https://forums.swift.org/t/mark-protocol-methods-with-their-protocol/4034/4 "2016-09-16T21:59:57Z")

</div>

Numerous solutions to your objection have been proposed; you always simply dismiss all of them in favor of your dogmatic stance. It’s really quite tiring. You can have this and support retroactive modeling; you just might need to have a separate syntax for retroactive conformances. You keep bringing that up as a hard-and-fast objection, but you know what? Maybe retroactive conformances should have a separate syntax, because they’re not saying the same thing! One is saying "here are some methods that will make this type conform to this protocol”, where the other is saying “this type already has the methods that conform to this protocol somewhere.” These are not the same thing, and it might be confusing to see a conformance declaration and assume it’s the former when it’s actually the latter, and then have trouble finding the conformances. Maybe it would actually make your code clearer if retroactive conformances were required to declare “this method exists somewhere else already.” Maybe you could even command-click on it and jump to the actual declaration. Anything would be better than the current situation, because:

The reason this keeps coming up is because it’s a real problem. I myself have started taking up the practice of always using copy-and-paste to declare conformances to protocols, because otherwise the chances of mistyping something and having the bug not manifest itself until runtime is simply too high. This is not a “linter” problem; this affects basic functionality and makes protocols, honestly, really dangerous to use. For a language that bills itself as “protocol-oriented”, it’s really quite damning that its protocol support is this brittle and fragile compared to its support for traditional inheritance. I’ve been bitten by this enough times by now to somewhat regret the decision to go with a protocol-based design. This is a real shame because conceptually, the idea of Swift’s protocol-based design is really cool.

Charles

> **···**
>
> On Sep 16, 2016, at 4:08 PM, Xiaodi Wu via swift-evolution \<swift-evolution@swift.org\> wrote:
> 
> > We've had this discussion on the list multiple times already. The gist of the difficulty here is that most proposals for a mandatory keyword don't permit retroactive modeling, so it's a no-go. On the other hand, the core team seems to take a dim view to optional syntax, since that's more in the ballpark of linters.

---

<div class="post-metadata">

**Author:** ![xwu](https://avatars.discourse-cdn.com/v4/letter/x/b487fb/32.png) [@xwu](https://forums.swift.org/u/xwu)\
**Post date:** [September 16, 2016, 9:08pm UTC](https://forums.swift.org/t/mark-protocol-methods-with-their-protocol/4034/5 "2016-09-16T21:08:45Z")

</div>

We've had this discussion on the list multiple times already. The gist of  
the difficulty here is that most proposals for a mandatory keyword don't  
permit retroactive modeling, so it's a no-go. On the other hand, the core  
team seems to take a dim view to optional syntax, since that's more in the  
ballpark of linters.

I really don't see anything new here that we haven't already discussed at  
length...

> **···**
>
> On Fri, Sep 16, 2016 at 15:25 Adrian Zubarev via swift-evolution \< swift-evolution@swift.org\> wrote:
> 
> > I don’t really like the idea of override(ProtocolName), but I’d support  
> > the single override here. On value types it’s easier to recognize the  
> > member of a protocol which had a default implementation.
> > 
> > I don’t feel like adding override to all members that replaces some  
> > default implementation will break anything. Furthermore, I’d love to see  
> > the addition where we could call the default implementation.
> > 
> > Here is some bikeshedding:
> > 
> > protocol A {}
> > 
> > extension A {  
> > &nbsp;&nbsp;&nbsp;func foo() { .. }  
> > }
> > 
> > protocol B : A {}
> > 
> > extension B {  
> > &nbsp;&nbsp;&nbsp;// overriding default implementation from an other one!?  
> > &nbsp;&nbsp;&nbsp;override func foo() {  
> > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;// call default implementation of A  
> > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;default.foo()  
> > &nbsp;&nbsp;&nbsp;&nbsp;}  
> > }
> > 
> > struct C : A {  
> > &nbsp;&nbsp;&nbsp;// overriding some default implementation  
> > &nbsp;&nbsp;&nbsp;override func foo() {  
> > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;// call default implementation  
> > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;default.foo()  
> > &nbsp;&nbsp;&nbsp;&nbsp;}  
> > }
> > 
> > struct D : B {  
> > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;// overriding some default implementation  
> > &nbsp;&nbsp;&nbsp;override func foo() {  
> > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;// call default implementation B  
> > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;// which will also call default implementation of A  
> > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;default.foo()  
> > &nbsp;&nbsp;&nbsp;&nbsp;}  
> > }
> > 
> > --  
> > Adrian Zubarev  
> > Sent with Airmail
> > 
> > Am 16. September 2016 um 20:45:05, Vladimir.S via swift-evolution (  
> > swift-evolution@swift.org) schrieb:
> > 
> > David, thank you for a real-word example when such feature will be very  
> > useful and can protect from hard-to-find bugs. IMO This shows that we  
> > should find a solution for the problem as soon as possible.
> > 
> > Such or similar question was discussed already in an number of threads,  
> > for  
> > example in "Requiring proactive overrides for default protocol  
> > implementations." and in "Requiring special keyword to mark protocol  
> > implementation methods", probably in other threads also.
> > 
> > The first is that `override` is not used in structs, so IMO it will be  
> > alien here.  
> > Second, if protocol has no default implementation for the method- would  
> > you  
> > require the `override(Protocol)` also?
> > 
> > Then, in case you will not require a keyword when no default  
> > implementation  
> > - you should think about retrospective adding of extension.
> > 
> > I.e. imagine, you have a source file, let's call it SomeClass.swift which  
> > you can't or don't want to change(this could be some complex source from  
> > 3rd party, from github, or from other developer of your company). This  
> > file  
> > compiles without problems. It contains:
> > 
> > public protocol Foo { func foo() }  
> > public class Some: Foo { func foo() {...} }
> > 
> > You added SomeClass.swift to your project and in your My.swift you added  
> > default implementation for Foo protocol:
> > 
> > extension Foo { func foo() {...} }
> > 
> > So, now, when you compile your project, there is default implementation  
> > for  
> > foo() and class Some should contains `override(Foo)`, but you can't change  
> > SomeClass.swift.
> > 
> > The only solution I see here, is if this `override(Foo)` will be optional,  
> > and just express developer's intention, if he/she wants this. I.e. it is  
> > not required, but if you specify it - compiler will check this intention.  
> > But AFAIR unfortunately someone from core team mentioned that they don't  
> > want such optional solution.
> > 
> > And, at the end, I do think the real reason of your problem is not that  
> > protocol method has default implementation, but that  
> > `viewController(with:properties:)` definition in `FooController` does not  
> > say for compiler(and compiler does not check this) that this method was  
> > defined \*exactly\* to confirm to protocol. I.e. you can't clearly express  
> > your intention regarding why this method is here. Check this example:
> > 
> > Let's assume you defined protocol Foo in FooProto.swift file:
> > 
> > public protocol Foo { func foo() }
> > 
> > and have class `Some` conformed to Foo in SomeClass.swift:
> > 
> > public class Some : Foo { func foo() {...} }
> > 
> > it is clear \*why\* foo is here..
> > 
> > OK, now, let's assume you changed Foo protocol in the way, that  
> > SomeClass.swift \*still\* compiles :
> > 
> > public protocol Foo { func bar() }  
> > extension Foo {  
> > func bar() {...}  
> > }
> > 
> > Now, SomeClass.swift still compiles but it contains \*wrong\* intention that  
> > foo() method is an implementation of protocol requirement. And this can  
> > lead to bugs/unexpected behavior.
> > 
> > I think what we do need a way to clearly shows intention that we defined  
> > some method \*exactly\* because the conformed protocol has it and to make  
> > compiler check this.
> > 
> > My favorite solution is 'implements' keyword inside class/struct to  
> > highlight that I defined this method as implementation for the protocol  
> > requirement. IMO solves a big percent of discussed issues with just one  
> > added keyword, that also will help with understanding the code when you  
> > read it.
> > 
> > Other solution that was mentioned by (as I remember) member of core team  
> > is  
> > treat class extension with protocol conformance as such intention, i.e.  
> > when you say  
> > extension Some: Foo {..}  
> > compiler will understand this as all methods inside such extension must  
> > 'belongs' to the Foo protocol, i.e. if there is some method that does not  
> > exist in Foo - it will raise an error. But in this case we need to require  
> > that each protocol conformance will be declared as extension, not inline  
> > in  
> > class definition. Personally I don't believe in this solution.
> > 
> > On 16.09.2016 18:29, David Beck via swift-evolution wrote:  
> > \> With the transition from Swift 2 -\> 3 IБ─≥ve started running into one  
> > \> particular issue VERY often (although itБ─≥s not necessarily specific to  
> > the  
> > \> transition). If a protocol method is optional (either because it is an  
> > \> @objc optional or because it has a default implementation) there is a  
> > risk  
> > \> that the conformer will have a misspelled or slightly incorrectly typed  
> > \> implementation of the method. For instance:  
> > \>  
> > \> protocolRouteDestinationViewController: class{  
> > \> staticfuncviewController(with url: URL, properties: [String:String]) -\>  
> > \> UIViewController?  
> > \> }  
> > \>  
> > \> extensionRouteDestinationViewControllerwhereSelf: UIViewController {  
> > \> staticfuncviewController(with url: URL, properties: [String:String]) -\>  
> > \> UIViewController? {  
> > \> returnSelf.init()  
> > \> }  
> > \> }  
> > \>  
> > \> classFooController: UIViewController, RouteDestinationViewController{  
> > \> staticfuncviewController(with url: URL, properties: [String:Any]) -\>  
> > \> UIViewController? {  
> > \> returnFooController(properties: properties)  
> > \> }  
> > \> }  
> > \>  
> > \> Notice the issue there? Properties is supposed to be [String:String], but  
> > \> FooController uses [String:Any] (this is an exact issue I ran into after  
> > a  
> > \> small refactor). When viewController(with:properties:) is called, it will  
> > \> use the default implementation instead of what the compiler sees as a  
> > \> completely different method. Over the betas the compiler has gotten  
> > better  
> > \> warnings about this, but is still not 100%.  
> > \>  
> > \> Other cases of this issue are common with imported ObjC protocols that  
> > have  
> > \> different naming in Swift. In some cases an @objc name must be applied to  
> > \> ensure it is declared in a way that the protocol can see it.  
> > \>  
> > \> We solve this problem with subclassing by requiring Б─°overrideБ─². If  
> > the  
> > \> override keyword is present but the superclass doesnБ─≥t have a matching  
> > \> method, the compiler warns us about it. Similarly if the superclass  
> > \> implements the same method and the subclass doesnБ─≥t include override,  
> > we  
> > \> get a warning so that it is clear that you are overriding behavior.  
> > \>  
> > \> For protocols, I donБ─≥t think a required keyword would be the best  
> > approach.  
> > \> ItБ─≥s a completely valid case that a type could conform to a protocol  
> > using  
> > \> existing methods, perhaps even from a different module. Further, a single  
> > \> method could satisfy multiple protocols, and be overriden from a  
> > \> superclass. What I would propose would be something like an optional  
> > \> override(\<#protocol name#\>). Something like the following:  
> > \>  
> > \> override(RouteDestinationViewController) staticfuncviewController(with  
> > url:  
> > \> URL, properties: [String:Any]) -\> UIViewController? {  
> > \> returnFooController(properties: properties)  
> > \> }  
> > \>  
> > \> A method should be able to include multiple overrides (including a bare  
> > \> override to indicate that it is overriding a class method).  
> > \>  
> > \> Thoughts? Are you seeing similar issues?  
> > \>  
> > \> \*David Beck\*  
> > \> [http://davidbeck.co](http://davidbeck.co)  
> > \> [http://twitter.com/davbeck](http://twitter.com/davbeck)  
> > \> [David Beck](http://facebook.com/davbeck)  
> > \>  
> > \>  
> > \>  
> > \> \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_  
> > \> swift-evolution mailing list  
> > \> swift-evolution@swift.org  
> > \> [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution)  
> > \>  
> > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_  
> > swift-evolution mailing list  
> > swift-evolution@swift.org  
> > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution)
> > 
> > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_  
> > swift-evolution mailing list  
> > swift-evolution@swift.org  
> > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution)

---

<div class="post-metadata">

**Author:** ![xwu](https://avatars.discourse-cdn.com/v4/letter/x/b487fb/32.png) [@xwu](https://forums.swift.org/u/xwu)\
**Post date:** [September 16, 2016, 11:45pm UTC](https://forums.swift.org/t/mark-protocol-methods-with-their-protocol/4034/6 "2016-09-16T23:45:22Z")

</div>

I absolutely agree that it's a problem worth solving. However, the question  
is whether a particular proposed design solves the problem and avoids  
previously stated weaknesses. What I'm saying here is that, so far, the  
conversation in this thread has involved reiterating already-proposed  
designs that have been critiqued. It's really quite tiring for me too to  
repeat the same critique when someone raises the same proposal a second or  
third time.

It's possible that it makes sense to have a separate syntax for retroactive  
modeling. I haven't been able to come up with one that seems reasonable to  
me, or I would have written to this list to propose it. Do you have such a  
design in mind?

> **···**
>
> On Fri, Sep 16, 2016 at 16:59 Charles Srstka \<cocoadev@charlessoft.com\> wrote:
> 
> > On Sep 16, 2016, at 4:08 PM, Xiaodi Wu via swift-evolution \< \> swift-evolution@swift.org\> wrote:
> > 
> > We've had this discussion on the list multiple times already. The gist of  
> > the difficulty here is that most proposals for a mandatory keyword don't  
> > permit retroactive modeling, so it's a no-go. On the other hand, the core  
> > team seems to take a dim view to optional syntax, since that's more in the  
> > ballpark of linters.
> > 
> > Numerous solutions to your objection have been proposed; you always simply  
> > dismiss all of them in favor of your dogmatic stance. It’s really quite  
> > tiring. You can have this and support retroactive modeling; you just might  
> > need to have a separate syntax for retroactive conformances. You keep  
> > bringing that up as a hard-and-fast objection, but you know what? Maybe  
> > retroactive conformances \*should\* have a separate syntax, because they’re  
> > not saying the same thing! One is saying "here are some methods that will  
> > make this type conform to this protocol”, where the other is saying “this  
> > type already has the methods that conform to this protocol somewhere.”  
> > These are not the same thing, and it might be confusing to see a  
> > conformance declaration and assume it’s the former when it’s actually the  
> > latter, and then have trouble finding the conformances. Maybe it would  
> > actually make your code clearer if retroactive conformances were required  
> > to declare “this method exists somewhere else already.” Maybe you could  
> > even command-click on it and jump to the actual declaration. Anything would  
> > be better than the current situation, because:
> > 
> > The reason this keeps coming up is because it’s a real problem. I myself  
> > have started taking up the practice of always using copy-and-paste to  
> > declare conformances to protocols, because otherwise the chances of  
> > mistyping something and having the bug not manifest itself until runtime is  
> > simply too high. This is not a “linter” problem; this affects basic  
> > functionality and makes protocols, honestly, really dangerous to use. For a  
> > language that bills itself as “protocol-oriented”, it’s really quite  
> > damning that its protocol support is this brittle and fragile compared to  
> > its support for traditional inheritance. I’ve been bitten by this enough  
> > times by now to somewhat regret the decision to go with a protocol-based  
> > design. This is a real shame because conceptually, the idea of Swift’s  
> > protocol-based design is really cool.
> > 
> > Charles

---

<div class="post-metadata">

**Author:** ![David\_Beck](https://avatars.discourse-cdn.com/v4/letter/d/c4cdca/32.png) [@David\_Beck](https://forums.swift.org/u/David_Beck)\
**Post date:** [September 16, 2016, 10:28pm UTC](https://forums.swift.org/t/mark-protocol-methods-with-their-protocol/4034/7 "2016-09-16T22:28:33Z")

</div>

Yeah, I figured it had probably come up before since I don’t follow evolution that closely, but it is, in my opinion and experience, Swift’s last pitfall. So many other pitfalls from ObjC and other languages have been solved with Swift, including this exact one (when it comes to subclassing). If we are going to say that it is a big enough problem to solve with a language feature for subclasses, it really seems like it would make sense to solve it for protocol conformance.

> **···**
>
> > On Sep 16, 2016, at 4:08 PM, Xiaodi Wu via swift-evolution\<swift-evolution@swift.org(mailto:swift-evolution@swift.org)\>wrote:  
> > \>  
> > \> We've had this discussion on the list multiple times already. The gist of the difficulty here is that most proposals for a mandatory keyword don't permit retroactive modeling, so it's a no-go. On the other hand, the core team seems to take a dim view to optional syntax, since that's more in the ballpark of linters.  
> > Numerous solutions to your objection have been proposed; you always simply dismiss all of them in favor of your dogmatic stance. It’s really quite tiring. You can have this and support retroactive modeling; you just might need to have a separate syntax for retroactive conformances. You keep bringing that up as a hard-and-fast objection, but you know what? Maybe retroactive conformancesshouldhave a separate syntax, because they’re not saying the same thing! One is saying "here are some methods that will make this type conform to this protocol”, where the other is saying “this type already has the methods that conform to this protocol somewhere.” These are not the same thing, and it might be confusing to see a conformance declaration and assume it’s the former when it’s actually the latter, and then have trouble finding the conformances. Maybe it would actually make your code clearer if retroactive conformances were required to declare “this method exists somewhere else already.” Maybe you could even command-click on it and jump to the actual declaration. Anything would be better than the current situation, because:
> > 
> > The reason this keeps coming up is because it’s a real problem. I myself have started taking up the practice of always using copy-and-paste to declare conformances to protocols, because otherwise the chances of mistyping something and having the bug not manifest itself until runtime is simply too high. This is not a “linter” problem; this affects basic functionality and makes protocols, honestly, really dangerous to use. For a language that bills itself as “protocol-oriented”, it’s really quite damning that its protocol support is this brittle and fragile compared to its support for traditional inheritance. I’ve been bitten by this enough times by now to somewhat regret the decision to go with a protocol-based design. This is a real shame because conceptually, the idea of Swift’s protocol-based design is really cool.
> > 
> > Charles
> 
> David Beck  
> [http://davidbeck.co](http://davidbeck.co)  
> [http://twitter.com/davbeck](http://twitter.com/davbeck)
> 
> > **[David Beck](https://www.facebook.com/davbeck)**
> >
> > David Beck is on Facebook. Join Facebook to connect with David Beck and others you may know. Facebook gives people the power to share and makes the world more open and connected.

---

<div class="post-metadata">

**Author:** ![David\_Goodine](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/david_goodine/32/11074_2.png) [@David\_Goodine](https://forums.swift.org/u/David_Goodine)\
**Post date:** [September 16, 2016, 11:59pm UTC](https://forums.swift.org/t/mark-protocol-methods-with-their-protocol/4034/8 "2016-09-16T23:59:18Z")

</div>

I'm not familiar with all of the discussions in other threads relating to this issue that some are here, so forgive me if I'm running over old ground.

Looking back at the original use case that David B. posted my first instinct was that this is a case that would best be solved by adding a compiler warning/error based on any function signature that matches a protocol signature but differs in the types.

My opinion is that naming a function that is so similar to a protocol function but clearly has a different signature is a bad idea and at least should be a warning. If Swift wants to be opinionated about it, it could become an error.

But looking at Vladimir's response, one thing that caught my interest was the idea of an 'implements' keyword. I think it might be a good addition to the language because it a) avoids this whole class of programming mistakes and, more importantly, b) strengthens the 'intention' of the programmer implementing the protocol, similarly to the way 'override' works for inherited functions.

One of the things I really like about Swift is that in many cases it requires programmers to explicitly state their intent when writing code (i.e. override). I think Vladimir's suggestion could do the same for protocols and should be considered.

> **···**
>
> Sent from my iPhone
> 
> > On Sep 16, 2016, at 6:28 PM, David Beck via swift-evolution \<swift-evolution@swift.org\> wrote:
> > 
> > Yeah, I figured it had probably come up before since I don’t follow evolution that closely, but it is, in my opinion and experience, Swift’s last pitfall. So many other pitfalls from ObjC and other languages have been solved with Swift, including this exact one (when it comes to subclassing). If we are going to say that it is a big enough problem to solve with a language feature for subclasses, it really seems like it would make sense to solve it for protocol conformance.
> > 
> > \> On Sep 16, 2016, at 4:08 PM, Xiaodi Wu via swift-evolution\<swift-evolution@swift.org(mailto:swift-evolution@swift.org)\>wrote:  
> > \> \>  
> > \> \> We've had this discussion on the list multiple times already. The gist of the difficulty here is that most proposals for a mandatory keyword don't permit retroactive modeling, so it's a no-go. On the other hand, the core team seems to take a dim view to optional syntax, since that's more in the ballpark of linters.  
> > \> Numerous solutions to your objection have been proposed; you always simply dismiss all of them in favor of your dogmatic stance. It’s really quite tiring. You can have this and support retroactive modeling; you just might need to have a separate syntax for retroactive conformances. You keep bringing that up as a hard-and-fast objection, but you know what? Maybe retroactive conformancesshouldhave a separate syntax, because they’re not saying the same thing! One is saying "here are some methods that will make this type conform to this protocol”, where the other is saying “this type already has the methods that conform to this protocol somewhere.” These are not the same thing, and it might be confusing to see a conformance declaration and assume it’s the former when it’s actually the latter, and then have trouble finding the conformances. Maybe it would actually make your code clearer if retroactive conformances were required to declare “this method exists somewhere else already.” Maybe you could even command-click on it and jump to the actual declaration. Anything would be better than the current situation, because:  
> > \>  
> > \> The reason this keeps coming up is because it’s a real problem. I myself have started taking up the practice of always using copy-and-paste to declare conformances to protocols, because otherwise the chances of mistyping something and having the bug not manifest itself until runtime is simply too high. This is not a “linter” problem; this affects basic functionality and makes protocols, honestly, really dangerous to use. For a language that bills itself as “protocol-oriented”, it’s really quite damning that its protocol support is this brittle and fragile compared to its support for traditional inheritance. I’ve been bitten by this enough times by now to somewhat regret the decision to go with a protocol-based design. This is a real shame because conceptually, the idea of Swift’s protocol-based design is really cool.  
> > \>  
> > \> Charles  
> > \>  
> > \>  
> > \>  
> > \>
> > 
> > David Beck  
> > [http://davidbeck.co](http://davidbeck.co)  
> > [http://twitter.com/davbeck](http://twitter.com/davbeck)  
> > [David Beck](http://facebook.com/davbeck)
> > 
> > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_  
> > swift-evolution mailing list  
> > swift-evolution@swift.org  
> > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution)

---

<div class="post-metadata">

**Author:** ![Karl](https://avatars.discourse-cdn.com/v4/letter/k/34f0e0/32.png) [@Karl](https://forums.swift.org/u/Karl)\
**Post date:** [September 17, 2016, 1:28am UTC](https://forums.swift.org/t/mark-protocol-methods-with-their-protocol/4034/9 "2016-09-17T01:28:03Z")

</div>

I don’t see what the big problem about retroactive modelling is.

Basically, the way I see it, if my class MyClass implements MyProtocol, providing someRequiredFunc(), there’s an “ownership” chain there (reading it backwards).

Now what happens if MyClass implements MyOtherProtocol, which also has someRequiredFunc()? In that case, I want to MyClass as a MyOtherProtocol and get another function pointer, which just happens to have the same human-readable name as some other property. Just because they have the same function signature, absolutely doesn’t mean they’re the same thing.

Now, if we strongly bind all protocol conformances to the protocol they implement, what happens to instance methods? They don’t belong to any protocol, their parent is the class itself. If you have an instance method called someRequiredFunc(), and you later add a conformance to MyProtocol, you would need to declare that it belongs to MyProtocol. If you don’t want it to be an API-breaking change, you have to provide a thunk (or we could provide a shorthand syntax which emits thunks for you) to let us know that MyClass::someRequiredFunc() is the same thing as MyClass::MyProtocol::someRequiredFunc().

Let’s take an example where retroactive modelling could go wrong. You’ve got different teams working on different parts of an App, and they’ve all got their own convention for “copy()”. Sometimes it’s a deep-copy, sometimes a shallow-copy, sometimes it’s used in a fragile way for a specific case, whatever. Now you want to go and clean that up by creating a “Copyable” protocol with codified guarantees. Some objects may already conform, others may need tweaks, and some may want both behaviours simultaneously (preserving the old, non-Copytable-compliant behaviour until the next API break), depending on how you look at the object. A system like this allows all of those different ways of looking at the object live together. You could have the old, non-comforming API as an extension with a FIXME to delete it for version 2.

I think it’s pretty arcane that members of a type are resolved only by their names. If you want to provide types which allow flexible views of data, each view of that data needs to be completely free in its expressivity.

I would actually like to see a syntax like:

```swift
let testObject = MyClass()
let testMyProto = testObject.MyProtocol // the protocol-witness table for testObject as a MyProtocol.

testObject.MyProtocol.someRequiredFunc() // that’s one function
testObject.someRequiredFunc() // is a different function. May happen to have the same implementation as above if MyProtocol was retroactively modelled.

```

I think it would fit well with the dispatch system for protocol extensions, too. I sometimes have code like the following:

```swift
protocol Base {}
protocol Derived : Base {}

extension Base { 
  func doSomething() { … }
}
extension Derived {
  func doSomething() {
   …
   (self as Base).doSomething() // Would be better if we could say “self.Base.doSomething()” to disambiguate instead of casting.
  }
}

```

So yeah, a big +1 to marking protocol methods with their protocol (whatever the syntax ends up looking like), and actually I’d take it further and bake them in to the ABI. That also makes it relevant for Swift 4 phase 1.

Karl

> **···**
>
> > On 17 Sep 2016, at 01:45, Xiaodi Wu via swift-evolution \<swift-evolution@swift.org\> wrote:
> > 
> > I absolutely agree that it's a problem worth solving. However, the question is whether a particular proposed design solves the problem and avoids previously stated weaknesses. What I'm saying here is that, so far, the conversation in this thread has involved reiterating already-proposed designs that have been critiqued. It's really quite tiring for me too to repeat the same critique when someone raises the same proposal a second or third time.
> > 
> > It's possible that it makes sense to have a separate syntax for retroactive modeling. I haven't been able to come up with one that seems reasonable to me, or I would have written to this list to propose it. Do you have such a design in mind?  
> > On Fri, Sep 16, 2016 at 16:59 Charles Srstka \<cocoadev@charlessoft.com \<mailto:cocoadev@charlessoft.com\>\> wrote:  
> > On Sep 16, 2016, at 4:08 PM, Xiaodi Wu via swift-evolution \<swift-evolution@swift.org \<mailto:swift-evolution@swift.org\>\> wrote:
> > 
> > > We've had this discussion on the list multiple times already. The gist of the difficulty here is that most proposals for a mandatory keyword don't permit retroactive modeling, so it's a no-go. On the other hand, the core team seems to take a dim view to optional syntax, since that's more in the ballpark of linters.
> > 
> > Numerous solutions to your objection have been proposed; you always simply dismiss all of them in favor of your dogmatic stance. It’s really quite tiring. You can have this and support retroactive modeling; you just might need to have a separate syntax for retroactive conformances. You keep bringing that up as a hard-and-fast objection, but you know what? Maybe retroactive conformances should have a separate syntax, because they’re not saying the same thing! One is saying "here are some methods that will make this type conform to this protocol”, where the other is saying “this type already has the methods that conform to this protocol somewhere.” These are not the same thing, and it might be confusing to see a conformance declaration and assume it’s the former when it’s actually the latter, and then have trouble finding the conformances. Maybe it would actually make your code clearer if retroactive conformances were required to declare “this method exists somewhere else already.” Maybe you could even command-click on it and jump to the actual declaration. Anything would be better than the current situation, because:
> > 
> > The reason this keeps coming up is because it’s a real problem. I myself have started taking up the practice of always using copy-and-paste to declare conformances to protocols, because otherwise the chances of mistyping something and having the bug not manifest itself until runtime is simply too high. This is not a “linter” problem; this affects basic functionality and makes protocols, honestly, really dangerous to use. For a language that bills itself as “protocol-oriented”, it’s really quite damning that its protocol support is this brittle and fragile compared to its support for traditional inheritance. I’ve been bitten by this enough times by now to somewhat regret the decision to go with a protocol-based design. This is a real shame because conceptually, the idea of Swift’s protocol-based design is really cool.
> > 
> > Charles
> > 
> > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_  
> > swift-evolution mailing list  
> > swift-evolution@swift.org  
> > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution)

---

<div class="post-metadata">

**Author:** ![xwu](https://avatars.discourse-cdn.com/v4/letter/x/b487fb/32.png) [@xwu](https://forums.swift.org/u/xwu)\
**Post date:** [September 17, 2016, 3:32am UTC](https://forums.swift.org/t/mark-protocol-methods-with-their-protocol/4034/10 "2016-09-17T03:32:13Z")

</div>

> I absolutely agree that it's a problem worth solving. However, the  
> question is whether a particular proposed design solves the problem and  
> avoids previously stated weaknesses. What I'm saying here is that, so far,  
> the conversation in this thread has involved reiterating already-proposed  
> designs that have been critiqued. It's really quite tiring for me too to  
> repeat the same critique when someone raises the same proposal a second or  
> third time.
> 
> It's possible that it makes sense to have a separate syntax for  
> retroactive modeling. I haven't been able to come up with one that seems  
> reasonable to me, or I would have written to this list to propose it. Do  
> you have such a design in mind?
> 
> > We've had this discussion on the list multiple times already. The gist of  
> > the difficulty here is that most proposals for a mandatory keyword don't  
> > permit retroactive modeling, so it's a no-go. On the other hand, the core  
> > team seems to take a dim view to optional syntax, since that's more in the  
> > ballpark of linters.
> > 
> > Numerous solutions to your objection have been proposed; you always  
> > simply dismiss all of them in favor of your dogmatic stance. It’s really  
> > quite tiring. You can have this and support retroactive modeling; you just  
> > might need to have a separate syntax for retroactive conformances. You keep  
> > bringing that up as a hard-and-fast objection, but you know what? Maybe  
> > retroactive conformances \*should\* have a separate syntax, because  
> > they’re not saying the same thing! One is saying "here are some methods  
> > that will make this type conform to this protocol”, where the other is  
> > saying “this type already has the methods that conform to this protocol  
> > somewhere.” These are not the same thing, and it might be confusing to see  
> > a conformance declaration and assume it’s the former when it’s actually the  
> > latter, and then have trouble finding the conformances. Maybe it would  
> > actually make your code clearer if retroactive conformances were required  
> > to declare “this method exists somewhere else already.” Maybe you could  
> > even command-click on it and jump to the actual declaration. Anything would  
> > be better than the current situation, because:
> > 
> > The reason this keeps coming up is because it’s a real problem. I myself  
> > have started taking up the practice of always using copy-and-paste to  
> > declare conformances to protocols, because otherwise the chances of  
> > mistyping something and having the bug not manifest itself until runtime is  
> > simply too high. This is not a “linter” problem; this affects basic  
> > functionality and makes protocols, honestly, really dangerous to use. For a  
> > language that bills itself as “protocol-oriented”, it’s really quite  
> > damning that its protocol support is this brittle and fragile compared to  
> > its support for traditional inheritance. I’ve been bitten by this enough  
> > times by now to somewhat regret the decision to go with a protocol-based  
> > design. This is a real shame because conceptually, the idea of Swift’s  
> > protocol-based design is really cool.
> > 
> > Charles
> > 
> > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
> 
> swift-evolution mailing list  
> swift-evolution@swift.org  
> [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution)
> 
> I don’t see what the big problem about retroactive modelling is.

Let me give a concrete example of how retroactively modeling is used.  
Currently, there is a JIRA bug that Set does not conform to SetAlgebra. To  
fix this issue, someone simply needs to write `extension Set : SetAlgebra {  
}` and some tests. That's literally what the bug (filed by a core team  
member) tells you to do. It's a starter bug, and if someone hasn't taken it  
yet, you the reader could have a go at it. What's neat about Swift is that  
it's super easy to provide the same functionality in your own project  
without waiting on that bug to be fixed in Swift itself. You can simply  
write a single line of code. By contrast, if your proposal were to be  
implemented, this would become much more difficult.

This is actively used in Swift today. For example, in the Swift  
implementation of NSScanner, you'll find the following lines:

```swift
internal protocol _BitShiftable {
    static func >>(lhs: Self, rhs: Self) -> Self
    static func <<(lhs: Self, rhs: Self) -> Self
}

internal protocol _IntegerLike : Integer, _BitShiftable {
    init(_ value: Int)
    static var max: Self { get }
    static var min: Self { get }
}

extension Int : _IntegerLike { }
extension Int32 : _IntegerLike { }
extension Int64 : _IntegerLike { }
extension UInt32 : _IntegerLike { }
extension UInt64 : _IntegerLike { }

```

If we adopted your proposed syntax below, it would take considerably more  
lines of boilerplate code to express the same thing. The burden increases  
significantly with the complexity of the retroactive modeling. For  
instance, if the retroactively modeled protocol had 20 requirements and you  
were retroactively conforming 20 types, that'd be at least 400 lines of  
boilerplate.

> Basically, the way I see it, if my class MyClass implements MyProtocol,  
> providing someRequiredFunc(), there’s an “ownership” chain there (reading  
> it backwards).
> 
> Now what happens if MyClass implements MyOtherProtocol, which also has  
> someRequiredFunc()? In that case, I want to MyClass as a MyOtherProtocol  
> and get another function pointer, which just happens to have the same  
> human-readable name as some other property. Just because they have the same  
> function signature, absolutely doesn’t mean they’re the same thing.
> 
> Now, if we strongly bind all protocol conformances to the protocol they  
> implement, what happens to instance methods? They don’t belong to any  
> protocol, their parent is the class itself. If you have an instance method  
> called someRequiredFunc(), and you later add a conformance to MyProtocol,  
> you would need to declare that it belongs to MyProtocol. If you don’t want  
> it to be an API-breaking change, you have to provide a thunk (or we could  
> provide a shorthand syntax which emits thunks for you) to let us know that  
> MyClass::someRequiredFunc() is the same thing as MyClass::MyProtocol::  
> someRequiredFunc().

Your argument is that two methods with the same name should not in any way  
conflict with each other. This is a fundamental change from the status quo.  
If we were to take your argument to its logical conclusion, any member A of  
a type T should be capable of being designated as the implementation of a  
requirement B of protocol P. In the most general case, two functions A and  
B shouldn't even need to take the same number of arguments, or arguments of  
the same type; you should be able to supply default arguments, or even  
write custom code that takes arguments for A and computes suitable  
arguments for B in order to forward A to B, and the language should allow  
you to designate A as an implementation of B. But that is simply not how  
Swift protocols are designed.

> Let’s take an example where retroactive modelling could go wrong. You’ve  
> got different teams working on different parts of an App, and they’ve all  
> got their own convention for “copy()”. Sometimes it’s a deep-copy,  
> sometimes a shallow-copy, sometimes it’s used in a fragile way for a  
> specific case, whatever. Now you want to go and clean that up by creating a  
> “Copyable” protocol with codified guarantees. Some objects may already  
> conform, others may need tweaks, and some may want both behaviours  
> simultaneously (preserving the old, non-Copytable-compliant behaviour until  
> the next API break), depending on how you look at the object. A system like  
> this allows all of those different ways of looking at the object live  
> together. You could have the old, non-comforming API as an extension with a  
> FIXME to delete it for version 2.

Even if you design a protocol called Copyable, you still need to explicitly  
extend concrete types in order to conform to Copyable. Swift does not  
automagically make anything conform to your protocol. If you choose  
\*explicitly\* to conform different types that don't guarantee the same  
semantics, and then you erroneously assume that they all have the same  
semantics even though you \*explicitly\* chose types that don't have the same  
semantics, you're the one who shot yourself in the foot, so to speak. It's  
not the fault of Swift at all.

> I think it’s pretty arcane that members of a type are resolved only by  
> their names. If you want to provide types which allow flexible views of  
> data, each view of that data needs to be completely free in its  
> expressivity.
> 
> I would actually like to see a syntax like:
> 
> ```swift
> let testObject = MyClass()
> let testMyProto = testObject.MyProtocol // the protocol-witness table for
> testObject as a MyProtocol.
> 
> testObject.MyProtocol.someRequiredFunc() // that’s one function
> testObject.someRequiredFunc() // is a different function. May happen to
> have the same implementation as above if MyProtocol was retroactively
> modelled.
> 
> ```
> 
> I think it would fit well with the dispatch system for protocol  
> extensions, too. I sometimes have code like the following:
> 
> ```swift
> protocol Base {}
> protocol Derived : Base {}
> 
> extension Base {
> func doSomething() { … }
> }
> extension Derived {
> func doSomething() {
> …
> (self as Base).doSomething() // Would be better if we could say
> “self.Base.doSomething()” to disambiguate instead of casting.
> }
> }
> 
> ```

This is a complete redesign of protocols in Swift. With the emphasis on  
minimizing source-breaking changes, I doubt such a change would be in scope  
for any phase of Swift unless you could show an overwhelming benefit.

So yeah, a big +1 to marking protocol methods with their protocol (whatever

> **···**
>
> On Fri, Sep 16, 2016 at 20:28 Karl \<razielim@gmail.com\> wrote:
> 
> > On 17 Sep 2016, at 01:45, Xiaodi Wu via swift-evolution \< \> swift-evolution@swift.org\> wrote:  
> > On Fri, Sep 16, 2016 at 16:59 Charles Srstka \<cocoadev@charlessoft.com\> \> wrote:
> > 
> > > On Sep 16, 2016, at 4:08 PM, Xiaodi Wu via swift-evolution \< \>\> swift-evolution@swift.org\> wrote:
> > 
> > the syntax ends up looking like), and actually I’d take it further and bake  
> > them in to the ABI. That also makes it relevant for Swift 4 phase 1.
> > 
> > Karl

---

<div class="post-metadata">

**Author:** ![Karl](https://avatars.discourse-cdn.com/v4/letter/k/34f0e0/32.png) [@Karl](https://forums.swift.org/u/Karl)\
**Post date:** [September 17, 2016, 5:21am UTC](https://forums.swift.org/t/mark-protocol-methods-with-their-protocol/4034/11 "2016-09-17T05:21:57Z")

</div>

> > I absolutely agree that it's a problem worth solving. However, the question is whether a particular proposed design solves the problem and avoids previously stated weaknesses. What I'm saying here is that, so far, the conversation in this thread has involved reiterating already-proposed designs that have been critiqued. It's really quite tiring for me too to repeat the same critique when someone raises the same proposal a second or third time.
> > 
> > It's possible that it makes sense to have a separate syntax for retroactive modeling. I haven't been able to come up with one that seems reasonable to me, or I would have written to this list to propose it. Do you have such a design in mind?
> > 
> > > We've had this discussion on the list multiple times already. The gist of the difficulty here is that most proposals for a mandatory keyword don't permit retroactive modeling, so it's a no-go. On the other hand, the core team seems to take a dim view to optional syntax, since that's more in the ballpark of linters.
> > 
> > Numerous solutions to your objection have been proposed; you always simply dismiss all of them in favor of your dogmatic stance. It’s really quite tiring. You can have this and support retroactive modeling; you just might need to have a separate syntax for retroactive conformances. You keep bringing that up as a hard-and-fast objection, but you know what? Maybe retroactive conformances should have a separate syntax, because they’re not saying the same thing! One is saying "here are some methods that will make this type conform to this protocol”, where the other is saying “this type already has the methods that conform to this protocol somewhere.” These are not the same thing, and it might be confusing to see a conformance declaration and assume it’s the former when it’s actually the latter, and then have trouble finding the conformances. Maybe it would actually make your code clearer if retroactive conformances were required to declare “this method exists somewhere else already.” Maybe you could even command-click on it and jump to the actual declaration. Anything would be better than the current situation, because:
> > 
> > The reason this keeps coming up is because it’s a real problem. I myself have started taking up the practice of always using copy-and-paste to declare conformances to protocols, because otherwise the chances of mistyping something and having the bug not manifest itself until runtime is simply too high. This is not a “linter” problem; this affects basic functionality and makes protocols, honestly, really dangerous to use. For a language that bills itself as “protocol-oriented”, it’s really quite damning that its protocol support is this brittle and fragile compared to its support for traditional inheritance. I’ve been bitten by this enough times by now to somewhat regret the decision to go with a protocol-based design. This is a real shame because conceptually, the idea of Swift’s protocol-based design is really cool.
> > 
> > Charles
> > 
> > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_  
> > swift-evolution mailing list  
> > swift-evolution@swift.org \<mailto:swift-evolution@swift.org\>  
> > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution)
> 
> I don’t see what the big problem about retroactive modelling is.
> 
> Let me give a concrete example of how retroactively modeling is used. Currently, there is a JIRA bug that Set does not conform to SetAlgebra. To fix this issue, someone simply needs to write `extension Set : SetAlgebra { }` and some tests. That's literally what the bug (filed by a core team member) tells you to do. It's a starter bug, and if someone hasn't taken it yet, you the reader could have a go at it. What's neat about Swift is that it's super easy to provide the same functionality in your own project without waiting on that bug to be fixed in Swift itself. You can simply write a single line of code. By contrast, if your proposal were to be implemented, this would become much more difficult.
> 
> This is actively used in Swift today. For example, in the Swift implementation of NSScanner, you'll find the following lines:
> 
> ```swift
> internal protocol _BitShiftable {
> static func >>(lhs: Self, rhs: Self) -> Self
> static func <<(lhs: Self, rhs: Self) -> Self
> }
> 
> internal protocol _IntegerLike : Integer, _BitShiftable {
> init(_ value: Int)
> static var max: Self { get }
> static var min: Self { get }
> }
> 
> extension Int : _IntegerLike { }
> extension Int32 : _IntegerLike { }
> extension Int64 : _IntegerLike { }
> extension UInt32 : _IntegerLike { }
> extension UInt64 : _IntegerLike { }
> 
> ```
> 
> If we adopted your proposed syntax below, it would take considerably more lines of boilerplate code to express the same thing. The burden increases significantly with the complexity of the retroactive modeling. For instance, if the retroactively modeled protocol had 20 requirements and you were retroactively conforming 20 types, that'd be at least 400 lines of boilerplate.

Yes, this is necessarily going to be a big chunk of boilerplate, because there are n integer types with no useful common ancestors. We could come up with all kinds of shorthands for making this easier, but there are basically two situations when adding a conformance of a new protocol P when there are existing members with the same names:

- You’re adapting the semantics of new protocol P to your internal way of working. You need a more advanced bridge between the two models which may require maintenance as your internal workings change. Nothing much we can do about that.  
- You’re ensuring capabilities which may be provided by other protocols. You want to forward to the implementation of P.member to your an existing protocol’s X.member because they have the same semantics.

Ideally, you would use a protocol extension for the latter case. It would say that “all types which conform to StandardLibraryBitShiftable conform to \_BitShiftable”. In this case, as we don’t have protocol-oriented Integers, and the current design makes this one particular case really annoying. We could probably have a shorthand syntax for this sort of case, too. I’m not worried about that at all; the important thing is that we get the semantics correct and that the model makes Swift types even more powerful. We can worry about reducing boilerplate later, because in theory it’s all about hooking up the correct protocol-witness table with the correct function pointer and we’ll have all the information to do that.

> Basically, the way I see it, if my class MyClass implements MyProtocol, providing someRequiredFunc(), there’s an “ownership” chain there (reading it backwards).
> 
> Now what happens if MyClass implements MyOtherProtocol, which also has someRequiredFunc()? In that case, I want to MyClass as a MyOtherProtocol and get another function pointer, which just happens to have the same human-readable name as some other property. Just because they have the same function signature, absolutely doesn’t mean they’re the same thing.
> 
> Now, if we strongly bind all protocol conformances to the protocol they implement, what happens to instance methods? They don’t belong to any protocol, their parent is the class itself. If you have an instance method called someRequiredFunc(), and you later add a conformance to MyProtocol, you would need to declare that it belongs to MyProtocol. If you don’t want it to be an API-breaking change, you have to provide a thunk (or we could provide a shorthand syntax which emits thunks for you) to let us know that MyClass::someRequiredFunc() is the same thing as MyClass::MyProtocol::someRequiredFunc().
> 
> Your argument is that two methods with the same name should not in any way conflict with each other. This is a fundamental change from the status quo. If we were to take your argument to its logical conclusion, any member A of a type T should be capable of being designated as the implementation of a requirement B of protocol P. In the most general case, two functions A and B shouldn't even need to take the same number of arguments, or arguments of the same type; you should be able to supply default arguments, or even write custom code that takes arguments for A and computes suitable arguments for B in order to forward A to B, and the language should allow you to designate A as an implementation of B. But that is simply not how Swift protocols are designed.

Yes, that’s my argument. Changing the status quo is basically what swift-evo is \_for\_.

And yes, you’ve basically got the concept - you should connect up the protocol requirement \<-\> implementation table by manually marking the protocol name on them (as the proposal says). Migration would be straight-forward.  
But actually, I do think this fits with how Swift protocols are designed. In Objective-C, anything that responds to the same selectors as NSCopying conforms to NSCopying, because Objective-C’s dispatch works by selector names. In Swift, as you point out later, you need to manually declare that conformance even if it responds to the equivalent of “-(id) copyWithZone:”. A Swift protocol is a guarantee of a certain kind of behaviour, not just of functions with certain names.

The status quo is that we are stuck in the middle - members are disambiguated only by their name, but just having the name isn’t enough for conformance. So when you come across a conflict in names, you need to rename all uses of one of them. If the protocol comes from a source you cannot change, you may be stuck in a situation where you \*cannot conform to the protocol\* and have to write your own wrapping thunk-er which does. Basically, you end up looking with code that looks like my proposal.

> Let’s take an example where retroactive modelling could go wrong. You’ve got different teams working on different parts of an App, and they’ve all got their own convention for “copy()”. Sometimes it’s a deep-copy, sometimes a shallow-copy, sometimes it’s used in a fragile way for a specific case, whatever. Now you want to go and clean that up by creating a “Copyable” protocol with codified guarantees. Some objects may already conform, others may need tweaks, and some may want both behaviours simultaneously (preserving the old, non-Copytable-compliant behaviour until the next API break), depending on how you look at the object. A system like this allows all of those different ways of looking at the object live together. You could have the old, non-comforming API as an extension with a FIXME to delete it for version 2.
> 
> Even if you design a protocol called Copyable, you still need to explicitly extend concrete types in order to conform to Copyable. Swift does not automagically make anything conform to your protocol. If you choose \*explicitly\* to conform different types that don't guarantee the same semantics, and then you erroneously assume that they all have the same semantics even though you \*explicitly\* chose types that don't have the same semantics, you're the one who shot yourself in the foot, so to speak. It's not the fault of Swift at all.

Yes, and the best bit about this is that you’d need to explicitly add it to every would-be member of Copyable too, so you’d have to check that the new semantics you are imposing with the conformance are correct (unless using some retroactive modelling shorthand which tells the compiler to emit thunks for all members of MyClass-\>Copyable in to MyClass). That’s the right thing to do, IMO (and also, would be the perfect cue for Xcode’s rename tool to start supporting Swift…).

> I think it’s pretty arcane that members of a type are resolved only by their names. If you want to provide types which allow flexible views of data, each view of that data needs to be completely free in its expressivity.
> 
> I would actually like to see a syntax like:
> 
> ```swift
> let testObject = MyClass()
> let testMyProto = testObject.MyProtocol // the protocol-witness table for testObject as a MyProtocol.
> 
> testObject.MyProtocol.someRequiredFunc() // that’s one function
> testObject.someRequiredFunc() // is a different function. May happen to have the same implementation as above if MyProtocol was retroactively modelled.
> 
> ```
> 
> I think it would fit well with the dispatch system for protocol extensions, too. I sometimes have code like the following:
> 
> ```swift
> protocol Base {}
> protocol Derived : Base {}
> 
> extension Base { 
> func doSomething() { … }
> }
> extension Derived {
> func doSomething() {
> …
> (self as Base).doSomething() // Would be better if we could say “self.Base.doSomething()” to disambiguate instead of casting.
> }
> }
> 
> ```
> 
> This is a complete redesign of protocols in Swift. With the emphasis on minimizing source-breaking changes, I doubt such a change would be in scope for any phase of Swift unless you could show an overwhelming benefit.

Not really a complete redesign - it fits with the semantic model of protocols which has already been established. I expect that protocols are going to change a lot in Swift 4 anyway, what with conditional conformances and better existentials, they’re going to be way more powerful than Swift 3 protocols. It is important we unlock full expressivity to allow them to be fully exploited, so we have to tackle the naming-conflict problem.

Also, I’m not sure source-breaking changes are such a big deal since we decided to support Swift 3 syntax. We could still support that - if you write “MyClass.someRequiredFunc()” which only exists inside a protocol, the compiler can search for the correct one to use.

There are great ways we can extend this, too - if you’ve got the ability to disambiguate the protocol witnesses yourself, perhaps you could override the “MyProtocol” witness getter and return an optimised wrapper which conforms to the protocol on your behalf. That would mean that all of the various String views (UTF8/16/Scalars/Characters) could be implemented as protocols on the single String type. So now suddenly we have a standard protocol for “a collection of UTF code points” which String is able to conform to, so it’s much easier to write generic code works with String and my own custom data-type which is also representable as some UTF code points.

I think that’s a pretty big win. It would allow us incredible new flexibility to model, which is ultimately what protocols are there to do.  
It’s not even such a big change \*\*at a high level\*\* (I’m aware that, especially the first one, would touch just about every component of the compiler and standard library):

- Protocol conformances own their members; Members which are part of a protocol conformance no longer belong to their enclosing type directly.  
- Synthesise getter for “.ProtocolName”, which returns the protocol witness  
- (Optional) Make overridable to supply your own protocol witness  
- Insert jumps to allow for retroactive modelling, with shorthand syntax

I’m not sure if it’s really a non-starter though. It would make the language much better and it would be pretty easy to migrate existing code (since we don’t allow non-unique names right now). Like I said, I expect the Swift 4 standard library (with conditional conformances) to look very different to Swift 3 at any rate.

> **···**
>
> > On 17 Sep 2016, at 05:32, Xiaodi Wu \<xiaodi.wu@gmail.com\> wrote:  
> > On Fri, Sep 16, 2016 at 20:28 Karl \<razielim@gmail.com \<mailto:razielim@gmail.com\>\> wrote:
> > 
> > > On 17 Sep 2016, at 01:45, Xiaodi Wu via swift-evolution \<swift-evolution@swift.org \<mailto:swift-evolution@swift.org\>\> wrote:  
> > > On Fri, Sep 16, 2016 at 16:59 Charles Srstka \<cocoadev@charlessoft.com \<mailto:cocoadev@charlessoft.com\>\> wrote:  
> > > On Sep 16, 2016, at 4:08 PM, Xiaodi Wu via swift-evolution \<swift-evolution@swift.org \<mailto:swift-evolution@swift.org\>\> wrote:
> 
> > So yeah, a big +1 to marking protocol methods with their protocol (whatever the syntax ends up looking like), and actually I’d take it further and bake them in to the ABI. That also makes it relevant for Swift 4 phase 1.
> > 
> > Karl

---

<div class="post-metadata">

**Author:** ![Karl](https://avatars.discourse-cdn.com/v4/letter/k/34f0e0/32.png) [@Karl](https://forums.swift.org/u/Karl)\
**Post date:** [September 17, 2016, 7:27am UTC](https://forums.swift.org/t/mark-protocol-methods-with-their-protocol/4034/12 "2016-09-17T07:27:54Z")

</div>

I started putting together a proposal, hopefully better explaining what I’m suggesting:

> <https://github.com/karwa/swift-evolution/blob/patch-2/0000-template.md>

> **···**
>
> > On 17 Sep 2016, at 05:32, Xiaodi Wu \<xiaodi.wu@gmail.com\> wrote:
> > 
> > On Fri, Sep 16, 2016 at 20:28 Karl \<razielim@gmail.com \<mailto:razielim@gmail.com\>\> wrote:
> > 
> > > On 17 Sep 2016, at 01:45, Xiaodi Wu via swift-evolution \<swift-evolution@swift.org \<mailto:swift-evolution@swift.org\>\> wrote:
> > > 
> > > I absolutely agree that it's a problem worth solving. However, the question is whether a particular proposed design solves the problem and avoids previously stated weaknesses. What I'm saying here is that, so far, the conversation in this thread has involved reiterating already-proposed designs that have been critiqued. It's really quite tiring for me too to repeat the same critique when someone raises the same proposal a second or third time.
> > > 
> > > It's possible that it makes sense to have a separate syntax for retroactive modeling. I haven't been able to come up with one that seems reasonable to me, or I would have written to this list to propose it. Do you have such a design in mind?  
> > > On Fri, Sep 16, 2016 at 16:59 Charles Srstka \<cocoadev@charlessoft.com \<mailto:cocoadev@charlessoft.com\>\> wrote:  
> > > On Sep 16, 2016, at 4:08 PM, Xiaodi Wu via swift-evolution \<swift-evolution@swift.org \<mailto:swift-evolution@swift.org\>\> wrote:
> > > 
> > > > We've had this discussion on the list multiple times already. The gist of the difficulty here is that most proposals for a mandatory keyword don't permit retroactive modeling, so it's a no-go. On the other hand, the core team seems to take a dim view to optional syntax, since that's more in the ballpark of linters.
> > > 
> > > Numerous solutions to your objection have been proposed; you always simply dismiss all of them in favor of your dogmatic stance. It’s really quite tiring. You can have this and support retroactive modeling; you just might need to have a separate syntax for retroactive conformances. You keep bringing that up as a hard-and-fast objection, but you know what? Maybe retroactive conformances should have a separate syntax, because they’re not saying the same thing! One is saying "here are some methods that will make this type conform to this protocol”, where the other is saying “this type already has the methods that conform to this protocol somewhere.” These are not the same thing, and it might be confusing to see a conformance declaration and assume it’s the former when it’s actually the latter, and then have trouble finding the conformances. Maybe it would actually make your code clearer if retroactive conformances were required to declare “this method exists somewhere else already.” Maybe you could even command-click on it and jump to the actual declaration. Anything would be better than the current situation, because:
> > > 
> > > The reason this keeps coming up is because it’s a real problem. I myself have started taking up the practice of always using copy-and-paste to declare conformances to protocols, because otherwise the chances of mistyping something and having the bug not manifest itself until runtime is simply too high. This is not a “linter” problem; this affects basic functionality and makes protocols, honestly, really dangerous to use. For a language that bills itself as “protocol-oriented”, it’s really quite damning that its protocol support is this brittle and fragile compared to its support for traditional inheritance. I’ve been bitten by this enough times by now to somewhat regret the decision to go with a protocol-based design. This is a real shame because conceptually, the idea of Swift’s protocol-based design is really cool.
> > > 
> > > Charles
> > > 
> > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_  
> > > swift-evolution mailing list  
> > > swift-evolution@swift.org \<mailto:swift-evolution@swift.org\>  
> > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution)
> > 
> > I don’t see what the big problem about retroactive modelling is.
> > 
> > Let me give a concrete example of how retroactively modeling is used. Currently, there is a JIRA bug that Set does not conform to SetAlgebra. To fix this issue, someone simply needs to write `extension Set : SetAlgebra { }` and some tests. That's literally what the bug (filed by a core team member) tells you to do. It's a starter bug, and if someone hasn't taken it yet, you the reader could have a go at it. What's neat about Swift is that it's super easy to provide the same functionality in your own project without waiting on that bug to be fixed in Swift itself. You can simply write a single line of code. By contrast, if your proposal were to be implemented, this would become much more difficult.
> > 
> > This is actively used in Swift today. For example, in the Swift implementation of NSScanner, you'll find the following lines:
> > 
> > ```swift
> > internal protocol _BitShiftable {
> > static func >>(lhs: Self, rhs: Self) -> Self
> > static func <<(lhs: Self, rhs: Self) -> Self
> > }
> > 
> > internal protocol _IntegerLike : Integer, _BitShiftable {
> > init(_ value: Int)
> > static var max: Self { get }
> > static var min: Self { get }
> > }
> > 
> > extension Int : _IntegerLike { }
> > extension Int32 : _IntegerLike { }
> > extension Int64 : _IntegerLike { }
> > extension UInt32 : _IntegerLike { }
> > extension UInt64 : _IntegerLike { }
> > 
> > ```
> > 
> > If we adopted your proposed syntax below, it would take considerably more lines of boilerplate code to express the same thing. The burden increases significantly with the complexity of the retroactive modeling. For instance, if the retroactively modeled protocol had 20 requirements and you were retroactively conforming 20 types, that'd be at least 400 lines of boilerplate.
> > 
> > Basically, the way I see it, if my class MyClass implements MyProtocol, providing someRequiredFunc(), there’s an “ownership” chain there (reading it backwards).
> > 
> > Now what happens if MyClass implements MyOtherProtocol, which also has someRequiredFunc()? In that case, I want to MyClass as a MyOtherProtocol and get another function pointer, which just happens to have the same human-readable name as some other property. Just because they have the same function signature, absolutely doesn’t mean they’re the same thing.
> > 
> > Now, if we strongly bind all protocol conformances to the protocol they implement, what happens to instance methods? They don’t belong to any protocol, their parent is the class itself. If you have an instance method called someRequiredFunc(), and you later add a conformance to MyProtocol, you would need to declare that it belongs to MyProtocol. If you don’t want it to be an API-breaking change, you have to provide a thunk (or we could provide a shorthand syntax which emits thunks for you) to let us know that MyClass::someRequiredFunc() is the same thing as MyClass::MyProtocol::someRequiredFunc().
> > 
> > Your argument is that two methods with the same name should not in any way conflict with each other. This is a fundamental change from the status quo. If we were to take your argument to its logical conclusion, any member A of a type T should be capable of being designated as the implementation of a requirement B of protocol P. In the most general case, two functions A and B shouldn't even need to take the same number of arguments, or arguments of the same type; you should be able to supply default arguments, or even write custom code that takes arguments for A and computes suitable arguments for B in order to forward A to B, and the language should allow you to designate A as an implementation of B. But that is simply not how Swift protocols are designed.
> > 
> > Let’s take an example where retroactive modelling could go wrong. You’ve got different teams working on different parts of an App, and they’ve all got their own convention for “copy()”. Sometimes it’s a deep-copy, sometimes a shallow-copy, sometimes it’s used in a fragile way for a specific case, whatever. Now you want to go and clean that up by creating a “Copyable” protocol with codified guarantees. Some objects may already conform, others may need tweaks, and some may want both behaviours simultaneously (preserving the old, non-Copytable-compliant behaviour until the next API break), depending on how you look at the object. A system like this allows all of those different ways of looking at the object live together. You could have the old, non-comforming API as an extension with a FIXME to delete it for version 2.
> > 
> > Even if you design a protocol called Copyable, you still need to explicitly extend concrete types in order to conform to Copyable. Swift does not automagically make anything conform to your protocol. If you choose \*explicitly\* to conform different types that don't guarantee the same semantics, and then you erroneously assume that they all have the same semantics even though you \*explicitly\* chose types that don't have the same semantics, you're the one who shot yourself in the foot, so to speak. It's not the fault of Swift at all.
> > 
> > I think it’s pretty arcane that members of a type are resolved only by their names. If you want to provide types which allow flexible views of data, each view of that data needs to be completely free in its expressivity.
> > 
> > I would actually like to see a syntax like:
> > 
> > ```swift
> > let testObject = MyClass()
> > let testMyProto = testObject.MyProtocol // the protocol-witness table for testObject as a MyProtocol.
> > 
> > testObject.MyProtocol.someRequiredFunc() // that’s one function
> > testObject.someRequiredFunc() // is a different function. May happen to have the same implementation as above if MyProtocol was retroactively modelled.
> > 
> > ```
> > 
> > I think it would fit well with the dispatch system for protocol extensions, too. I sometimes have code like the following:
> > 
> > ```swift
> > protocol Base {}
> > protocol Derived : Base {}
> > 
> > extension Base { 
> > func doSomething() { … }
> > }
> > extension Derived {
> > func doSomething() {
> > …
> > (self as Base).doSomething() // Would be better if we could say “self.Base.doSomething()” to disambiguate instead of casting.
> > }
> > }
> > 
> > ```
> > 
> > This is a complete redesign of protocols in Swift. With the emphasis on minimizing source-breaking changes, I doubt such a change would be in scope for any phase of Swift unless you could show an overwhelming benefit.
> > 
> > So yeah, a big +1 to marking protocol methods with their protocol (whatever the syntax ends up looking like), and actually I’d take it further and bake them in to the ABI. That also makes it relevant for Swift 4 phase 1.
> > 
> > Karl

---

<div class="post-metadata">

**Author:** ![VladimirS](https://avatars.discourse-cdn.com/v4/letter/v/f9ae1b/32.png) [@VladimirS](https://forums.swift.org/u/VladimirS)\
**Post date:** [September 19, 2016, 5:10pm UTC](https://forums.swift.org/t/mark-protocol-methods-with-their-protocol/4034/13 "2016-09-19T17:10:46Z")

</div>

> Let me give a concrete example of how retroactively modeling is used.

Karl is suggesting interesting but complex and IMO too much code-breaking idea that I don't believe can be implemented at all in a reasonable amount of time to be a part of Swift as soon as possible, to address the discussed issue with protocols.

I wonder what objections could be made on the solution proposed below, which should solve a major(IMO) number of issues with protocol conformance and introduce only 1 keyword. Such solution will make Swift better as Protocol-Oriented language and later we can even improve it, but it can already solve a big number of issues:

1. As soon as possible we add 'implement' keyword which is required to mark method/property that was defined in type or extension exactly to conform to some protocol.

2. The 'implement' required only at a moment of 'direct' conformance, i.e. when you declare methods/props of the type/extension that explicitly conformed to protocol.

3. Retrospective conformance will not require this keyword and will work for now just like it is working today.

4. Later, if this will be possible at all, we can extend this model to support separate implementation of protocols with same requirements in the same type, explicit protocol name in implemented methods/props and improvements for retrospective conformance. For example some variants for \*future\* improvements:

4.1 Different implementation for different protocols  
class Foo : ProtocolA, ProtocolB {  
&nbsp;&nbsp;&nbsp;implement(ProtocolA) func foo() {...}  
&nbsp;&nbsp;&nbsp;implement(ProtocolB) func foo() {...}  
}  
class Foo : ProtocolA, ProtocolB {  
&nbsp;&nbsp;&nbsp;implement ProtocolA {  
&nbsp;&nbsp;&nbsp;&nbsp;func foo() {...}  
&nbsp;&nbsp;&nbsp;}  
&nbsp;&nbsp;&nbsp;implement ProtocolB {  
&nbsp;&nbsp;&nbsp;&nbsp;func foo() {...}  
&nbsp;&nbsp;&nbsp;}  
}  
etc

4.2 Retrospective conformance: What is the main problem with retrospective conformance? As I see it now(correct me, if I missing something), the problem arises in such situation:  
\* we \*expect\* that some method(s) in type will play the role of implementation of protocol's requirements, so we retrospectively conform that type to the protocol.  
\* but protocol has default implementation for its requirements  
\* and type's methods, that we \*expect\* to play roles for protocol implementation, has different parameters or slightly different method name at all.

I.e. when we have this set of code logic:

type T {  
&nbsp;&nbsp;&nbsp;func foo()  
}

protocol P {  
&nbsp;&nbsp;&nbsp;func foo(x: Int)  
}

extension P {  
&nbsp;&nbsp;&nbsp;func foo(x: Int) {...}  
}

extension T : P { // expect foo in T will play role of P.foo  
}

I support the opinion that it is not an option to require to explicitly list conformed methods/props in type extension for retrospective conformance.  
But I do believe we need a way to \*express our intention\* regarding the retrospective conformance: do we expect that type already contains implementation for some protocol's requirements OR we are aware that protocol can have defaults for some methods and our type does not contains some implementations.

So, the solution here IMO is some syntax to express that intention. Right now I think that we can use current syntax "extension T : P" to keep it working as it now works: "I'm aware of all the names, defaults etc. Treat this as usually you did". But for example something like "extension T: implement P {..}" or "extension T: P(implement \*) {..}" will say that we \*expect\* that all requirements of P protocol should be implemented inside T type. Or some syntax inside extension to specify the list of methods/props we expect to be implemented in T. Or "extension T : P(implement foo, bar(x:y:)) {..}".. Should be discussed.

But again, IMO this could be discussed later, after we'll have 'implement' for most important place - in type definition for method/prop that we created exactly for the conformed protocol.

Opinions?

> **···**
>
> On 17.09.2016 6:32, Xiaodi Wu via swift-evolution wrote:
> 
> > Currently, there is a JIRA bug that Set does not conform to SetAlgebra. To  
> > fix this issue, someone simply needs to write `extension Set : SetAlgebra {  
> > }` and some tests. That's literally what the bug (filed by a core team  
> > member) tells you to do. It's a starter bug, and if someone hasn't taken it  
> > yet, you the reader could have a go at it. What's neat about Swift is that  
> > it's super easy to provide the same functionality in your own project  
> > without waiting on that bug to be fixed in Swift itself. You can simply  
> > write a single line of code. By contrast, if your proposal were to be  
> > implemented, this would become much more difficult.
> > 
> > This is actively used in Swift today. For example, in the Swift  
> > implementation of NSScanner, you'll find the following lines:
> > 
> > ```swift
> > internal protocol _BitShiftable {
> > static func >>(lhs: Self, rhs: Self) -> Self
> > static func <<(lhs: Self, rhs: Self) -> Self
> > }
> > 
> > internal protocol _IntegerLike : Integer, _BitShiftable {
> > init(_ value: Int)
> > static var max: Self { get }
> > static var min: Self { get }
> > }
> > 
> > extension Int : _IntegerLike { }
> > extension Int32 : _IntegerLike { }
> > extension Int64 : _IntegerLike { }
> > extension UInt32 : _IntegerLike { }
> > extension UInt64 : _IntegerLike { }
> > 
> > ```
> > 
> > If we adopted your proposed syntax below, it would take considerably more  
> > lines of boilerplate code to express the same thing. The burden increases  
> > significantly with the complexity of the retroactive modeling. For  
> > instance, if the retroactively modeled protocol had 20 requirements and you  
> > were retroactively conforming 20 types, that'd be at least 400 lines of  
> > boilerplate.
> > 
> > &nbsp;&nbsp;&nbsp;&nbsp;Basically, the way I see it, if my class MyClass implements MyProtocol,  
> > &nbsp;&nbsp;&nbsp;&nbsp;providing someRequiredFunc(), there’s an “ownership” chain there  
> > &nbsp;&nbsp;&nbsp;&nbsp;(reading it backwards).
> > 
> > &nbsp;&nbsp;&nbsp;&nbsp;Now what happens if MyClass implements MyOtherProtocol, which also has  
> > &nbsp;&nbsp;&nbsp;&nbsp;someRequiredFunc()? In that case, I want to MyClass as a  
> > &nbsp;&nbsp;&nbsp;&nbsp;MyOtherProtocol and get another function pointer, which just happens to  
> > &nbsp;&nbsp;&nbsp;&nbsp;have the same human-readable name as some other property. Just because  
> > &nbsp;&nbsp;&nbsp;&nbsp;they have the same function signature, absolutely doesn’t mean they’re  
> > &nbsp;&nbsp;&nbsp;&nbsp;the same thing.
> > 
> > &nbsp;&nbsp;&nbsp;&nbsp;Now, if we strongly bind all protocol conformances to the protocol they  
> > &nbsp;&nbsp;&nbsp;&nbsp;implement, what happens to instance methods? They don’t belong to any  
> > &nbsp;&nbsp;&nbsp;&nbsp;protocol, their parent is the class itself. If you have an instance  
> > &nbsp;&nbsp;&nbsp;&nbsp;method called someRequiredFunc(), and you later add a conformance to  
> > &nbsp;&nbsp;&nbsp;&nbsp;MyProtocol, you would need to declare that it belongs to MyProtocol. If  
> > &nbsp;&nbsp;&nbsp;&nbsp;you don’t want it to be an API-breaking change, you have to provide a  
> > &nbsp;&nbsp;&nbsp;&nbsp;thunk (or we could provide a shorthand syntax which emits thunks for  
> > &nbsp;&nbsp;&nbsp;&nbsp;you) to let us know that MyClass::someRequiredFunc() is the same thing  
> > &nbsp;&nbsp;&nbsp;&nbsp;as MyClass::MyProtocol::someRequiredFunc().
> > 
> > Your argument is that two methods with the same name should not in any way  
> > conflict with each other. This is a fundamental change from the status quo.  
> > If we were to take your argument to its logical conclusion, any member A of  
> > a type T should be capable of being designated as the implementation of a  
> > requirement B of protocol P. In the most general case, two functions A and  
> > B shouldn't even need to take the same number of arguments, or arguments of  
> > the same type; you should be able to supply default arguments, or even  
> > write custom code that takes arguments for A and computes suitable  
> > arguments for B in order to forward A to B, and the language should allow  
> > you to designate A as an implementation of B. But that is simply not how  
> > Swift protocols are designed.
> > 
> > &nbsp;&nbsp;&nbsp;&nbsp;Let’s take an example where retroactive modelling could go wrong.  
> > &nbsp;&nbsp;&nbsp;&nbsp;You’ve got different teams working on different parts of an App, and  
> > &nbsp;&nbsp;&nbsp;&nbsp;they’ve all got their own convention for “copy()”. Sometimes it’s a  
> > &nbsp;&nbsp;&nbsp;&nbsp;deep-copy, sometimes a shallow-copy, sometimes it’s used in a fragile  
> > &nbsp;&nbsp;&nbsp;&nbsp;way for a specific case, whatever. Now you want to go and clean that up  
> > &nbsp;&nbsp;&nbsp;&nbsp;by creating a “Copyable” protocol with codified guarantees. Some  
> > &nbsp;&nbsp;&nbsp;&nbsp;objects may already conform, others may need tweaks, and some may want  
> > &nbsp;&nbsp;&nbsp;&nbsp;both behaviours simultaneously (preserving the old,  
> > &nbsp;&nbsp;&nbsp;&nbsp;non-Copytable-compliant behaviour until the next API break), depending  
> > &nbsp;&nbsp;&nbsp;&nbsp;on how you look at the object. A system like this allows all of those  
> > &nbsp;&nbsp;&nbsp;&nbsp;different ways of looking at the object live together. You could have  
> > &nbsp;&nbsp;&nbsp;&nbsp;the old, non-comforming API as an extension with a FIXME to delete it  
> > &nbsp;&nbsp;&nbsp;&nbsp;for version 2.
> > 
> > Even if you design a protocol called Copyable, you still need to explicitly  
> > extend concrete types in order to conform to Copyable. Swift does not  
> > automagically make anything conform to your protocol. If you choose  
> > \*explicitly\* to conform different types that don't guarantee the same  
> > semantics, and then you erroneously assume that they all have the same  
> > semantics even though you \*explicitly\* chose types that don't have the same  
> > semantics, you're the one who shot yourself in the foot, so to speak. It's  
> > not the fault of Swift at all.
> > 
> > &nbsp;&nbsp;&nbsp;&nbsp;I think it’s pretty arcane that members of a type are resolved only by  
> > &nbsp;&nbsp;&nbsp;&nbsp;their names. If you want to provide types which allow flexible views of  
> > &nbsp;&nbsp;&nbsp;&nbsp;data, each view of that data needs to be completely free in its  
> > &nbsp;&nbsp;&nbsp;&nbsp;expressivity.
> > 
> > &nbsp;&nbsp;&nbsp;&nbsp;I would actually like to see a syntax like:
> > 
> > &nbsp;&nbsp;&nbsp;&nbsp;```  
> > &nbsp;&nbsp;&nbsp;&nbsp;let testObject = MyClass()  
> > &nbsp;&nbsp;&nbsp;&nbsp;let testMyProto = testObject.MyProtocol // the protocol-witness table  
> > &nbsp;&nbsp;&nbsp;&nbsp;for testObject as a MyProtocol.
> > 
> > &nbsp;&nbsp;&nbsp;&nbsp;testObject.MyProtocol.someRequiredFunc() // that’s one function  
> > &nbsp;&nbsp;&nbsp;&nbsp;testObject.someRequiredFunc() // is a different function. May happen to  
> > &nbsp;&nbsp;&nbsp;&nbsp;have the same implementation as above if MyProtocol was retroactively  
> > &nbsp;&nbsp;&nbsp;&nbsp;modelled.  
> > &nbsp;&nbsp;&nbsp;&nbsp;```
> > 
> > &nbsp;&nbsp;&nbsp;&nbsp;I think it would fit well with the dispatch system for protocol  
> > &nbsp;&nbsp;&nbsp;&nbsp;extensions, too. I sometimes have code like the following:
> > 
> > &nbsp;&nbsp;&nbsp;&nbsp;```  
> > &nbsp;&nbsp;&nbsp;&nbsp;protocol Base {}  
> > &nbsp;&nbsp;&nbsp;&nbsp;protocol Derived : Base {}
> > 
> > &nbsp;&nbsp;&nbsp;&nbsp;extension Base {  
> > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;func doSomething() { … }  
> > &nbsp;&nbsp;&nbsp;&nbsp;}  
> > &nbsp;&nbsp;&nbsp;&nbsp;extension Derived {  
> > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;func doSomething() {  
> > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;…  
> > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;(self as Base).doSomething() // Would be better if we could say  
> > &nbsp;&nbsp;&nbsp;&nbsp;“self.Base.doSomething()” to disambiguate instead of casting.  
> > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;}  
> > &nbsp;&nbsp;&nbsp;&nbsp;}  
> > &nbsp;&nbsp;&nbsp;&nbsp;```
> > 
> > This is a complete redesign of protocols in Swift. With the emphasis on  
> > minimizing source-breaking changes, I doubt such a change would be in scope  
> > for any phase of Swift unless you could show an overwhelming benefit.
> > 
> > &nbsp;&nbsp;&nbsp;&nbsp;So yeah, a big +1 to marking protocol methods with their protocol  
> > &nbsp;&nbsp;&nbsp;&nbsp;(whatever the syntax ends up looking like), and actually I’d take it  
> > &nbsp;&nbsp;&nbsp;&nbsp;further and bake them in to the ABI. That also makes it relevant for  
> > &nbsp;&nbsp;&nbsp;&nbsp;Swift 4 phase 1.
> > 
> > &nbsp;&nbsp;&nbsp;&nbsp;Karl
> > 
> > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_  
> > swift-evolution mailing list  
> > swift-evolution@swift.org  
> > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution)

---

<div class="post-metadata">

**Author:** ![Charles\_Srstka](https://avatars.discourse-cdn.com/v4/letter/c/0ea827/32.png) [@Charles\_Srstka](https://forums.swift.org/u/Charles_Srstka)\
**Post date:** [September 19, 2016, 6:18pm UTC](https://forums.swift.org/t/mark-protocol-methods-with-their-protocol/4034/14 "2016-09-19T18:18:59Z")

</div>

I would be completely +1 on this.

Charles

> **···**
>
> > On Sep 19, 2016, at 12:10 PM, Vladimir.S via swift-evolution \<swift-evolution@swift.org\> wrote:
> > 
> > On 17.09.2016 6:32, Xiaodi Wu via swift-evolution wrote:
> > 
> > > Let me give a concrete example of how retroactively modeling is used.
> > 
> > Karl is suggesting interesting but complex and IMO too much code-breaking idea that I don't believe can be implemented at all in a reasonable amount of time to be a part of Swift as soon as possible, to address the discussed issue with protocols.
> > 
> > I wonder what objections could be made on the solution proposed below, which should solve a major(IMO) number of issues with protocol conformance and introduce only 1 keyword. Such solution will make Swift better as Protocol-Oriented language and later we can even improve it, but it can already solve a big number of issues:
> > 
> > 1. As soon as possible we add 'implement' keyword which is required to mark method/property that was defined in type or extension exactly to conform to some protocol.
> > 
> > 2. The 'implement' required only at a moment of 'direct' conformance, i.e. when you declare methods/props of the type/extension that explicitly conformed to protocol.
> > 
> > 3. Retrospective conformance will not require this keyword and will work for now just like it is working today.
> > 
> > 4. Later, if this will be possible at all, we can extend this model to support separate implementation of protocols with same requirements in the same type, explicit protocol name in implemented methods/props and improvements for retrospective conformance. For example some variants for \*future\* improvements:
> > 
> > 4.1 Different implementation for different protocols  
> > class Foo : ProtocolA, ProtocolB {  
> > implement(ProtocolA) func foo() {...}  
> > implement(ProtocolB) func foo() {...}  
> > }  
> > class Foo : ProtocolA, ProtocolB {  
> > implement ProtocolA {  
> > &nbsp;&nbsp;func foo() {...}  
> > }  
> > implement ProtocolB {  
> > &nbsp;&nbsp;func foo() {...}  
> > }  
> > }  
> > etc
> > 
> > 4.2 Retrospective conformance: What is the main problem with retrospective conformance? As I see it now(correct me, if I missing something), the problem arises in such situation:  
> > \* we \*expect\* that some method(s) in type will play the role of implementation of protocol's requirements, so we retrospectively conform that type to the protocol.  
> > \* but protocol has default implementation for its requirements  
> > \* and type's methods, that we \*expect\* to play roles for protocol implementation, has different parameters or slightly different method name at all.
> > 
> > I.e. when we have this set of code logic:
> > 
> > type T {  
> > func foo()  
> > }
> > 
> > protocol P {  
> > func foo(x: Int)  
> > }
> > 
> > extension P {  
> > func foo(x: Int) {...}  
> > }
> > 
> > extension T : P { // expect foo in T will play role of P.foo  
> > }
> > 
> > I support the opinion that it is not an option to require to explicitly list conformed methods/props in type extension for retrospective conformance.  
> > But I do believe we need a way to \*express our intention\* regarding the retrospective conformance: do we expect that type already contains implementation for some protocol's requirements OR we are aware that protocol can have defaults for some methods and our type does not contains some implementations.
> > 
> > So, the solution here IMO is some syntax to express that intention. Right now I think that we can use current syntax "extension T : P" to keep it working as it now works: "I'm aware of all the names, defaults etc. Treat this as usually you did". But for example something like "extension T: implement P {..}" or "extension T: P(implement \*) {..}" will say that we \*expect\* that all requirements of P protocol should be implemented inside T type. Or some syntax inside extension to specify the list of methods/props we expect to be implemented in T. Or "extension T : P(implement foo, bar(x:y:)) {..}".. Should be discussed.
> > 
> > But again, IMO this could be discussed later, after we'll have 'implement' for most important place - in type definition for method/prop that we created exactly for the conformed protocol.

---

<div class="post-metadata">

**Author:** ![Panajev](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/panajev/32/1227_2.png) [@Panajev](https://forums.swift.org/u/Panajev)\
**Post date:** [September 19, 2016, 8:10pm UTC](https://forums.swift.org/t/mark-protocol-methods-with-their-protocol/4034/15 "2016-09-19T20:10:12Z")

</div>

If Swift 4 will make it impossible to tackle this again, I do not think discussing this can be avoided for Swift 3.1... I am afraid we are rushing into Swift 4 a bit too quickly, but perhaps it is just silly old me :).

> **···**
>
> Sent from my iPhone
> 
> > On 19 Sep 2016, at 19:18, Charles Srstka via swift-evolution \<swift-evolution@swift.org\> wrote:
> > 
> > > On Sep 19, 2016, at 12:10 PM, Vladimir.S via swift-evolution \<swift-evolution@swift.org\> wrote:
> > > 
> > > > On 17.09.2016 6:32, Xiaodi Wu via swift-evolution wrote:
> > > > 
> > > > Let me give a concrete example of how retroactively modeling is used.
> > > 
> > > Karl is suggesting interesting but complex and IMO too much code-breaking idea that I don't believe can be implemented at all in a reasonable amount of time to be a part of Swift as soon as possible, to address the discussed issue with protocols.
> > > 
> > > I wonder what objections could be made on the solution proposed below, which should solve a major(IMO) number of issues with protocol conformance and introduce only 1 keyword. Such solution will make Swift better as Protocol-Oriented language and later we can even improve it, but it can already solve a big number of issues:
> > > 
> > > 1. As soon as possible we add 'implement' keyword which is required to mark method/property that was defined in type or extension exactly to conform to some protocol.
> > > 
> > > 2. The 'implement' required only at a moment of 'direct' conformance, i.e. when you declare methods/props of the type/extension that explicitly conformed to protocol.
> > > 
> > > 3. Retrospective conformance will not require this keyword and will work for now just like it is working today.
> > > 
> > > 4. Later, if this will be possible at all, we can extend this model to support separate implementation of protocols with same requirements in the same type, explicit protocol name in implemented methods/props and improvements for retrospective conformance. For example some variants for \*future\* improvements:
> > > 
> > > 4.1 Different implementation for different protocols  
> > > class Foo : ProtocolA, ProtocolB {  
> > > implement(ProtocolA) func foo() {...}  
> > > implement(ProtocolB) func foo() {...}  
> > > }  
> > > class Foo : ProtocolA, ProtocolB {  
> > > implement ProtocolA {  
> > > &nbsp;&nbsp;func foo() {...}  
> > > }  
> > > implement ProtocolB {  
> > > &nbsp;&nbsp;func foo() {...}  
> > > }  
> > > }  
> > > etc
> > > 
> > > 4.2 Retrospective conformance: What is the main problem with retrospective conformance? As I see it now(correct me, if I missing something), the problem arises in such situation:  
> > > \* we \*expect\* that some method(s) in type will play the role of implementation of protocol's requirements, so we retrospectively conform that type to the protocol.  
> > > \* but protocol has default implementation for its requirements  
> > > \* and type's methods, that we \*expect\* to play roles for protocol implementation, has different parameters or slightly different method name at all.
> > > 
> > > I.e. when we have this set of code logic:
> > > 
> > > type T {  
> > > func foo()  
> > > }
> > > 
> > > protocol P {  
> > > func foo(x: Int)  
> > > }
> > > 
> > > extension P {  
> > > func foo(x: Int) {...}  
> > > }
> > > 
> > > extension T : P { // expect foo in T will play role of P.foo  
> > > }
> > > 
> > > I support the opinion that it is not an option to require to explicitly list conformed methods/props in type extension for retrospective conformance.  
> > > But I do believe we need a way to \*express our intention\* regarding the retrospective conformance: do we expect that type already contains implementation for some protocol's requirements OR we are aware that protocol can have defaults for some methods and our type does not contains some implementations.
> > > 
> > > So, the solution here IMO is some syntax to express that intention. Right now I think that we can use current syntax "extension T : P" to keep it working as it now works: "I'm aware of all the names, defaults etc. Treat this as usually you did". But for example something like "extension T: implement P {..}" or "extension T: P(implement \*) {..}" will say that we \*expect\* that all requirements of P protocol should be implemented inside T type. Or some syntax inside extension to specify the list of methods/props we expect to be implemented in T. Or "extension T : P(implement foo, bar(x:y:)) {..}".. Should be discussed.
> > > 
> > > But again, IMO this could be discussed later, after we'll have 'implement' for most important place - in type definition for method/prop that we created exactly for the conformed protocol.
> > 
> > I would be completely +1 on this.
> > 
> > Charles
> > 
> > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_  
> > swift-evolution mailing list  
> > swift-evolution@swift.org  
> > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution)

---

<div class="post-metadata">

**Author:** ![Panajev](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/panajev/32/1227_2.png) [@Panajev](https://forums.swift.org/u/Panajev)\
**Post date:** [September 19, 2016, 8:10pm UTC](https://forums.swift.org/t/mark-protocol-methods-with-their-protocol/4034/16 "2016-09-19T20:10:52Z")

</div>

+1

> **···**
>
> Sent from my iPhone
> 
> > On 19 Sep 2016, at 18:10, Vladimir.S via swift-evolution \<swift-evolution@swift.org\> wrote:
> > 
> > > On 17.09.2016 6:32, Xiaodi Wu via swift-evolution wrote:
> > > 
> > > Let me give a concrete example of how retroactively modeling is used.
> > 
> > Karl is suggesting interesting but complex and IMO too much code-breaking idea that I don't believe can be implemented at all in a reasonable amount of time to be a part of Swift as soon as possible, to address the discussed issue with protocols.
> > 
> > I wonder what objections could be made on the solution proposed below, which should solve a major(IMO) number of issues with protocol conformance and introduce only 1 keyword. Such solution will make Swift better as Protocol-Oriented language and later we can even improve it, but it can already solve a big number of issues:
> > 
> > 1. As soon as possible we add 'implement' keyword which is required to mark method/property that was defined in type or extension exactly to conform to some protocol.
> > 
> > 2. The 'implement' required only at a moment of 'direct' conformance, i.e. when you declare methods/props of the type/extension that explicitly conformed to protocol.
> > 
> > 3. Retrospective conformance will not require this keyword and will work for now just like it is working today.
> > 
> > 4. Later, if this will be possible at all, we can extend this model to support separate implementation of protocols with same requirements in the same type, explicit protocol name in implemented methods/props and improvements for retrospective conformance. For example some variants for \*future\* improvements:
> > 
> > 4.1 Different implementation for different protocols  
> > class Foo : ProtocolA, ProtocolB {  
> > implement(ProtocolA) func foo() {...}  
> > implement(ProtocolB) func foo() {...}  
> > }  
> > class Foo : ProtocolA, ProtocolB {  
> > implement ProtocolA {  
> > &nbsp;&nbsp;&nbsp;func foo() {...}  
> > }  
> > implement ProtocolB {  
> > &nbsp;&nbsp;&nbsp;func foo() {...}  
> > }  
> > }  
> > etc
> > 
> > 4.2 Retrospective conformance: What is the main problem with retrospective conformance? As I see it now(correct me, if I missing something), the problem arises in such situation:  
> > \* we \*expect\* that some method(s) in type will play the role of implementation of protocol's requirements, so we retrospectively conform that type to the protocol.  
> > \* but protocol has default implementation for its requirements  
> > \* and type's methods, that we \*expect\* to play roles for protocol implementation, has different parameters or slightly different method name at all.
> > 
> > I.e. when we have this set of code logic:
> > 
> > type T {  
> > func foo()  
> > }
> > 
> > protocol P {  
> > func foo(x: Int)  
> > }
> > 
> > extension P {  
> > func foo(x: Int) {...}  
> > }
> > 
> > extension T : P { // expect foo in T will play role of P.foo  
> > }
> > 
> > I support the opinion that it is not an option to require to explicitly list conformed methods/props in type extension for retrospective conformance.  
> > But I do believe we need a way to \*express our intention\* regarding the retrospective conformance: do we expect that type already contains implementation for some protocol's requirements OR we are aware that protocol can have defaults for some methods and our type does not contains some implementations.
> > 
> > So, the solution here IMO is some syntax to express that intention. Right now I think that we can use current syntax "extension T : P" to keep it working as it now works: "I'm aware of all the names, defaults etc. Treat this as usually you did". But for example something like "extension T: implement P {..}" or "extension T: P(implement \*) {..}" will say that we \*expect\* that all requirements of P protocol should be implemented inside T type. Or some syntax inside extension to specify the list of methods/props we expect to be implemented in T. Or "extension T : P(implement foo, bar(x:y:)) {..}".. Should be discussed.
> > 
> > But again, IMO this could be discussed later, after we'll have 'implement' for most important place - in type definition for method/prop that we created exactly for the conformed protocol.
> > 
> > Opinions?
> > 
> > > Currently, there is a JIRA bug that Set does not conform to SetAlgebra. To  
> > > fix this issue, someone simply needs to write `extension Set : SetAlgebra {  
> > > }` and some tests. That's literally what the bug (filed by a core team  
> > > member) tells you to do. It's a starter bug, and if someone hasn't taken it  
> > > yet, you the reader could have a go at it. What's neat about Swift is that  
> > > it's super easy to provide the same functionality in your own project  
> > > without waiting on that bug to be fixed in Swift itself. You can simply  
> > > write a single line of code. By contrast, if your proposal were to be  
> > > implemented, this would become much more difficult.
> > > 
> > > This is actively used in Swift today. For example, in the Swift  
> > > implementation of NSScanner, you'll find the following lines:
> > > 
> > > ```swift
> > > internal protocol _BitShiftable {
> > > static func >>(lhs: Self, rhs: Self) -> Self
> > > static func <<(lhs: Self, rhs: Self) -> Self
> > > }
> > > 
> > > internal protocol _IntegerLike : Integer, _BitShiftable {
> > > init(_ value: Int)
> > > static var max: Self { get }
> > > static var min: Self { get }
> > > }
> > > 
> > > extension Int : _IntegerLike { }
> > > extension Int32 : _IntegerLike { }
> > > extension Int64 : _IntegerLike { }
> > > extension UInt32 : _IntegerLike { }
> > > extension UInt64 : _IntegerLike { }
> > > 
> > > ```
> > > 
> > > If we adopted your proposed syntax below, it would take considerably more  
> > > lines of boilerplate code to express the same thing. The burden increases  
> > > significantly with the complexity of the retroactive modeling. For  
> > > instance, if the retroactively modeled protocol had 20 requirements and you  
> > > were retroactively conforming 20 types, that'd be at least 400 lines of  
> > > boilerplate.
> > > 
> > > &nbsp;&nbsp;&nbsp;Basically, the way I see it, if my class MyClass implements MyProtocol,  
> > > &nbsp;&nbsp;&nbsp;providing someRequiredFunc(), there’s an “ownership” chain there  
> > > &nbsp;&nbsp;&nbsp;(reading it backwards).
> > > 
> > > &nbsp;&nbsp;&nbsp;Now what happens if MyClass implements MyOtherProtocol, which also has  
> > > &nbsp;&nbsp;&nbsp;someRequiredFunc()? In that case, I want to MyClass as a  
> > > &nbsp;&nbsp;&nbsp;MyOtherProtocol and get another function pointer, which just happens to  
> > > &nbsp;&nbsp;&nbsp;have the same human-readable name as some other property. Just because  
> > > &nbsp;&nbsp;&nbsp;they have the same function signature, absolutely doesn’t mean they’re  
> > > &nbsp;&nbsp;&nbsp;the same thing.
> > > 
> > > &nbsp;&nbsp;&nbsp;Now, if we strongly bind all protocol conformances to the protocol they  
> > > &nbsp;&nbsp;&nbsp;implement, what happens to instance methods? They don’t belong to any  
> > > &nbsp;&nbsp;&nbsp;protocol, their parent is the class itself. If you have an instance  
> > > &nbsp;&nbsp;&nbsp;method called someRequiredFunc(), and you later add a conformance to  
> > > &nbsp;&nbsp;&nbsp;MyProtocol, you would need to declare that it belongs to MyProtocol. If  
> > > &nbsp;&nbsp;&nbsp;you don’t want it to be an API-breaking change, you have to provide a  
> > > &nbsp;&nbsp;&nbsp;thunk (or we could provide a shorthand syntax which emits thunks for  
> > > &nbsp;&nbsp;&nbsp;you) to let us know that MyClass::someRequiredFunc() is the same thing  
> > > &nbsp;&nbsp;&nbsp;as MyClass::MyProtocol::someRequiredFunc().
> > > 
> > > Your argument is that two methods with the same name should not in any way  
> > > conflict with each other. This is a fundamental change from the status quo.  
> > > If we were to take your argument to its logical conclusion, any member A of  
> > > a type T should be capable of being designated as the implementation of a  
> > > requirement B of protocol P. In the most general case, two functions A and  
> > > B shouldn't even need to take the same number of arguments, or arguments of  
> > > the same type; you should be able to supply default arguments, or even  
> > > write custom code that takes arguments for A and computes suitable  
> > > arguments for B in order to forward A to B, and the language should allow  
> > > you to designate A as an implementation of B. But that is simply not how  
> > > Swift protocols are designed.
> > > 
> > > &nbsp;&nbsp;&nbsp;Let’s take an example where retroactive modelling could go wrong.  
> > > &nbsp;&nbsp;&nbsp;You’ve got different teams working on different parts of an App, and  
> > > &nbsp;&nbsp;&nbsp;they’ve all got their own convention for “copy()”. Sometimes it’s a  
> > > &nbsp;&nbsp;&nbsp;deep-copy, sometimes a shallow-copy, sometimes it’s used in a fragile  
> > > &nbsp;&nbsp;&nbsp;way for a specific case, whatever. Now you want to go and clean that up  
> > > &nbsp;&nbsp;&nbsp;by creating a “Copyable” protocol with codified guarantees. Some  
> > > &nbsp;&nbsp;&nbsp;objects may already conform, others may need tweaks, and some may want  
> > > &nbsp;&nbsp;&nbsp;both behaviours simultaneously (preserving the old,  
> > > &nbsp;&nbsp;&nbsp;non-Copytable-compliant behaviour until the next API break), depending  
> > > &nbsp;&nbsp;&nbsp;on how you look at the object. A system like this allows all of those  
> > > &nbsp;&nbsp;&nbsp;different ways of looking at the object live together. You could have  
> > > &nbsp;&nbsp;&nbsp;the old, non-comforming API as an extension with a FIXME to delete it  
> > > &nbsp;&nbsp;&nbsp;for version 2.
> > > 
> > > Even if you design a protocol called Copyable, you still need to explicitly  
> > > extend concrete types in order to conform to Copyable. Swift does not  
> > > automagically make anything conform to your protocol. If you choose  
> > > \*explicitly\* to conform different types that don't guarantee the same  
> > > semantics, and then you erroneously assume that they all have the same  
> > > semantics even though you \*explicitly\* chose types that don't have the same  
> > > semantics, you're the one who shot yourself in the foot, so to speak. It's  
> > > not the fault of Swift at all.
> > > 
> > > &nbsp;&nbsp;&nbsp;I think it’s pretty arcane that members of a type are resolved only by  
> > > &nbsp;&nbsp;&nbsp;their names. If you want to provide types which allow flexible views of  
> > > &nbsp;&nbsp;&nbsp;data, each view of that data needs to be completely free in its  
> > > &nbsp;&nbsp;&nbsp;expressivity.
> > > 
> > > &nbsp;&nbsp;&nbsp;I would actually like to see a syntax like:
> > > 
> > > ```swift
> > > let testObject = MyClass()
> > > let testMyProto = testObject.MyProtocol // the protocol-witness table
> > > for testObject as a MyProtocol.
> > > 
> > > testObject.MyProtocol.someRequiredFunc() // that’s one function
> > > testObject.someRequiredFunc() // is a different function. May happen to
> > > have the same implementation as above if MyProtocol was retroactively
> > > modelled.
> > > 
> > > ```
> > > 
> > > &nbsp;&nbsp;&nbsp;I think it would fit well with the dispatch system for protocol  
> > > &nbsp;&nbsp;&nbsp;extensions, too. I sometimes have code like the following:
> > > 
> > > ```swift
> > > protocol Base {}
> > > protocol Derived : Base {}
> > > 
> > > extension Base {
> > > func doSomething() { … }
> > > }
> > > extension Derived {
> > > func doSomething() {
> > > …
> > > (self as Base).doSomething() // Would be better if we could say
> > > “self.Base.doSomething()” to disambiguate instead of casting.
> > > }
> > > }
> > > 
> > > ```
> > > 
> > > This is a complete redesign of protocols in Swift. With the emphasis on  
> > > minimizing source-breaking changes, I doubt such a change would be in scope  
> > > for any phase of Swift unless you could show an overwhelming benefit.
> > > 
> > > &nbsp;&nbsp;&nbsp;So yeah, a big +1 to marking protocol methods with their protocol  
> > > &nbsp;&nbsp;&nbsp;(whatever the syntax ends up looking like), and actually I’d take it  
> > > &nbsp;&nbsp;&nbsp;further and bake them in to the ABI. That also makes it relevant for  
> > > &nbsp;&nbsp;&nbsp;Swift 4 phase 1.
> > > 
> > > &nbsp;&nbsp;&nbsp;Karl
> > > 
> > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_  
> > > swift-evolution mailing list  
> > > swift-evolution@swift.org  
> > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution)
> > 
> > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_  
> > swift-evolution mailing list  
> > swift-evolution@swift.org  
> > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution)

---

<div class="post-metadata">

**Author:** ![xwu](https://avatars.discourse-cdn.com/v4/letter/x/b487fb/32.png) [@xwu](https://forums.swift.org/u/xwu)\
**Post date:** [September 20, 2016, 12:03am UTC](https://forums.swift.org/t/mark-protocol-methods-with-their-protocol/4034/17 "2016-09-20T00:03:45Z")

</div>

I definitely think Vladimir's suggestion is a great starting point, IMO.

However, I think it could be improved in one key respect where previous  
proposals using `override` are superior. Namely, the proposed `implement`  
keyword adds no additional safety when a type implements a protocol  
requirement that doesn't have a default implementation. This is because, if  
there's a "near-miss" typo in the function signature, an error is already  
generated at compile time because the type doesn't conform to the stated  
protocol. Currently, the error is very unhelpful, but IMO that's a  
straight-up bug; improving the diagnostics for that error can be done  
without evolution.

On the other hand, if we require `implement`, the simplest use case of  
conforming a type to a protocol with no default implementations would take  
more effort but provide no benefit to justify that additional effort.  
Moreover (I think a core team member has expressed this more elegantly in  
the past), there's the philosophical point that POP represents the  
theoretical process by which we discover and express our discovery that  
certain types happen to share common semantic characteristics. In that  
conception of POP, it would be backwards to declare a certain member as  
fulfilling certain protocol requirements.

So, if such a source breaking change were to be in scope for Swift, I would  
suggest modifying Vladimir's proposal to use `override` instead and  
requiring the keyword only when a default implementation is being  
overridden. To accommodate retroactive conformance, we could either propose  
that `extension Foo : Bar` is automatically understood to contain members  
that override default implementations (as Vladimir has essentially  
suggested), or stipulate that we must write `extension Foo : override Bar`.  
This has the advantage of not introducing an additional keyword and avoids  
the seemingly reduplicative spelling `extension Foo : implement Bar` (for  
what else would an `extension Foo : Bar` reasonably do but implement the  
requirements of Bar?).

> **···**
>
> On Mon, Sep 19, 2016 at 3:10 PM, Goffredo Marocchi via swift-evolution \< swift-evolution@swift.org\> wrote:
> 
> > If Swift 4 will make it impossible to tackle this again, I do not think  
> > discussing this can be avoided for Swift 3.1... I am afraid we are rushing  
> > into Swift 4 a bit too quickly, but perhaps it is just silly old me :).
> > 
> > Sent from my iPhone
> > 
> > On 19 Sep 2016, at 19:18, Charles Srstka via swift-evolution \< \> swift-evolution@swift.org\> wrote:
> > 
> > On Sep 19, 2016, at 12:10 PM, Vladimir.S via swift-evolution \< \> swift-evolution@swift.org\> wrote:
> > 
> > On 17.09.2016 6:32, Xiaodi Wu via swift-evolution wrote:
> > 
> > Let me give a concrete example of how retroactively modeling is used.
> > 
> > Karl is suggesting interesting but complex and IMO too much code-breaking  
> > idea that I don't believe can be implemented at all in a reasonable amount  
> > of time to be a part of Swift as soon as possible, to address the discussed  
> > issue with protocols.
> > 
> > I wonder what objections could be made on the solution proposed below,  
> > which should solve a major(IMO) number of issues with protocol conformance  
> > and introduce only 1 keyword. Such solution will make Swift better as  
> > Protocol-Oriented language and later we can even improve it, but it can  
> > already solve a big number of issues:
> > 
> > 1. As soon as possible we add 'implement' keyword which is required to  
> > mark method/property that was defined in type or extension exactly to  
> > conform to some protocol.
> > 
> > 2. The 'implement' required only at a moment of 'direct' conformance, i.e.  
> > when you declare methods/props of the type/extension that explicitly  
> > conformed to protocol.
> > 
> > 3. Retrospective conformance will not require this keyword and will work  
> > for now just like it is working today.
> > 
> > 4. Later, if this will be possible at all, we can extend this model to  
> > support separate implementation of protocols with same requirements in the  
> > same type, explicit protocol name in implemented methods/props and  
> > improvements for retrospective conformance. For example some variants for  
> > \*future\* improvements:
> > 
> > 4.1 Different implementation for different protocols  
> > class Foo : ProtocolA, ProtocolB {  
> > implement(ProtocolA) func foo() {...}  
> > implement(ProtocolB) func foo() {...}  
> > }  
> > class Foo : ProtocolA, ProtocolB {  
> > implement ProtocolA {  
> > func foo() {...}  
> > }  
> > implement ProtocolB {  
> > func foo() {...}  
> > }  
> > }  
> > etc
> > 
> > 4.2 Retrospective conformance: What is the main problem with retrospective  
> > conformance? As I see it now(correct me, if I missing something), the  
> > problem arises in such situation:  
> > \* we \*expect\* that some method(s) in type will play the role of  
> > implementation of protocol's requirements, so we retrospectively conform  
> > that type to the protocol.  
> > \* but protocol has default implementation for its requirements  
> > \* and type's methods, that we \*expect\* to play roles for protocol  
> > implementation, has different parameters or slightly different method name  
> > at all.
> > 
> > I.e. when we have this set of code logic:
> > 
> > type T {  
> > func foo()  
> > }
> > 
> > protocol P {  
> > func foo(x: Int)  
> > }
> > 
> > extension P {  
> > func foo(x: Int) {...}  
> > }
> > 
> > extension T : P { // expect foo in T will play role of P.foo  
> > }
> > 
> > I support the opinion that it is not an option to require to explicitly  
> > list conformed methods/props in type extension for retrospective  
> > conformance.  
> > But I do believe we need a way to \*express our intention\* regarding the  
> > retrospective conformance: do we expect that type already contains  
> > implementation for some protocol's requirements OR we are aware that  
> > protocol can have defaults for some methods and our type does not contains  
> > some implementations.
> > 
> > So, the solution here IMO is some syntax to express that intention. Right  
> > now I think that we can use current syntax "extension T : P" to keep it  
> > working as it now works: "I'm aware of all the names, defaults etc. Treat  
> > this as usually you did". But for example something like "extension T:  
> > implement P {..}" or "extension T: P(implement \*) {..}" will say that we  
> > \*expect\* that all requirements of P protocol should be implemented inside T  
> > type. Or some syntax inside extension to specify the list of methods/props  
> > we expect to be implemented in T. Or "extension T : P(implement foo,  
> > bar(x:y:)) {..}".. Should be discussed.
> > 
> > But again, IMO this could be discussed later, after we'll have 'implement'  
> > for most important place - in type definition for method/prop that we  
> > created exactly for the conformed protocol.
> > 
> > I would be completely +1 on this.
> > 
> > Charles
> > 
> > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_  
> > swift-evolution mailing list  
> > swift-evolution@swift.org  
> > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution)
> > 
> > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_  
> > swift-evolution mailing list  
> > swift-evolution@swift.org  
> > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution)

---

<div class="post-metadata">

**Author:** ![Boris\_Wang](https://avatars.discourse-cdn.com/v4/letter/b/8dc957/32.png) [@Boris\_Wang](https://forums.swift.org/u/Boris_Wang)\
**Post date:** [September 20, 2016, 12:00am UTC](https://forums.swift.org/t/mark-protocol-methods-with-their-protocol/4034/18 "2016-09-20T00:00:11Z")

</div>

swift mixed implemention of protocol method and other method，this triggered  
the problem.

Compiler can't judge mis-spelled method. It think it's a new method.

Rust has no this problem:

Impl protocolName for className {  
.....  
}

linter can't check for mis-spelled methods, on the condition that there's  
no explicit override syntax in  
Swift.

Goffredo Marocchi via swift-evolution \<swift-evolution@swift.org\>于2016年9月20日  
周二04:12写道：

> **···**
>
> > +1
> > 
> > Sent from my iPhone
> > 
> > On 19 Sep 2016, at 18:10, Vladimir.S via swift-evolution \< \> swift-evolution@swift.org\> wrote:
> > 
> > On 17.09.2016 6:32, Xiaodi Wu via swift-evolution wrote:
> > 
> > Let me give a concrete example of how retroactively modeling is used.
> > 
> > Karl is suggesting interesting but complex and IMO too much code-breaking  
> > idea that I don't believe can be implemented at all in a reasonable amount  
> > of time to be a part of Swift as soon as possible, to address the discussed  
> > issue with protocols.
> > 
> > I wonder what objections could be made on the solution proposed below,  
> > which should solve a major(IMO) number of issues with protocol conformance  
> > and introduce only 1 keyword. Such solution will make Swift better as  
> > Protocol-Oriented language and later we can even improve it, but it can  
> > already solve a big number of issues:
> > 
> > 1. As soon as possible we add 'implement' keyword which is required to  
> > mark method/property that was defined in type or extension exactly to  
> > conform to some protocol.
> > 
> > 2. The 'implement' required only at a moment of 'direct' conformance, i.e.  
> > when you declare methods/props of the type/extension that explicitly  
> > conformed to protocol.
> > 
> > 3. Retrospective conformance will not require this keyword and will work  
> > for now just like it is working today.
> > 
> > 4. Later, if this will be possible at all, we can extend this model to  
> > support separate implementation of protocols with same requirements in the  
> > same type, explicit protocol name in implemented methods/props and  
> > improvements for retrospective conformance. For example some variants for  
> > \*future\* improvements:
> > 
> > 4.1 Different implementation for different protocols  
> > class Foo : ProtocolA, ProtocolB {  
> > implement(ProtocolA) func foo() {...}  
> > implement(ProtocolB) func foo() {...}  
> > }  
> > class Foo : ProtocolA, ProtocolB {  
> > implement ProtocolA {  
> > &nbsp;&nbsp;&nbsp;func foo() {...}  
> > }  
> > implement ProtocolB {  
> > &nbsp;&nbsp;&nbsp;func foo() {...}  
> > }  
> > }  
> > etc
> > 
> > 4.2 Retrospective conformance: What is the main problem with retrospective  
> > conformance? As I see it now(correct me, if I missing something), the  
> > problem arises in such situation:  
> > \* we \*expect\* that some method(s) in type will play the role of  
> > implementation of protocol's requirements, so we retrospectively conform  
> > that type to the protocol.  
> > \* but protocol has default implementation for its requirements  
> > \* and type's methods, that we \*expect\* to play roles for protocol  
> > implementation, has different parameters or slightly different method name  
> > at all.
> > 
> > I.e. when we have this set of code logic:
> > 
> > type T {  
> > func foo()  
> > }
> > 
> > protocol P {  
> > func foo(x: Int)  
> > }
> > 
> > extension P {  
> > func foo(x: Int) {...}  
> > }
> > 
> > extension T : P { // expect foo in T will play role of P.foo  
> > }
> > 
> > I support the opinion that it is not an option to require to explicitly  
> > list conformed methods/props in type extension for retrospective  
> > conformance.  
> > But I do believe we need a way to \*express our intention\* regarding the  
> > retrospective conformance: do we expect that type already contains  
> > implementation for some protocol's requirements OR we are aware that  
> > protocol can have defaults for some methods and our type does not contains  
> > some implementations.
> > 
> > So, the solution here IMO is some syntax to express that intention. Right  
> > now I think that we can use current syntax "extension T : P" to keep it  
> > working as it now works: "I'm aware of all the names, defaults etc. Treat  
> > this as usually you did". But for example something like "extension T:  
> > implement P {..}" or "extension T: P(implement \*) {..}" will say that we  
> > \*expect\* that all requirements of P protocol should be implemented inside T  
> > type. Or some syntax inside extension to specify the list of methods/props  
> > we expect to be implemented in T. Or "extension T : P(implement foo,  
> > bar(x:y:)) {..}".. Should be discussed.
> > 
> > But again, IMO this could be discussed later, after we'll have 'implement'  
> > for most important place - in type definition for method/prop that we  
> > created exactly for the conformed protocol.
> > 
> > Opinions?
> > 
> > Currently, there is a JIRA bug that Set does not conform to SetAlgebra. To
> > 
> > fix this issue, someone simply needs to write `extension Set : SetAlgebra {
> > 
> > }` and some tests. That's literally what the bug (filed by a core team
> > 
> > member) tells you to do. It's a starter bug, and if someone hasn't taken it
> > 
> > yet, you the reader could have a go at it. What's neat about Swift is that
> > 
> > it's super easy to provide the same functionality in your own project
> > 
> > without waiting on that bug to be fixed in Swift itself. You can simply
> > 
> > write a single line of code. By contrast, if your proposal were to be
> > 
> > implemented, this would become much more difficult.
> > 
> > This is actively used in Swift today. For example, in the Swift
> > 
> > implementation of NSScanner, you'll find the following lines:
> > 
> > ```swift
> > 
> > internal protocol _BitShiftable {
> > 
> > static func >>(lhs: Self, rhs: Self) -> Self
> > 
> > static func <<(lhs: Self, rhs: Self) -> Self
> > 
> > }
> > 
> > internal protocol _IntegerLike : Integer, _BitShiftable {
> > 
> > init(_ value: Int)
> > 
> > static var max: Self { get }
> > 
> > static var min: Self { get }
> > 
> > }
> > 
> > extension Int : _IntegerLike { }
> > 
> > extension Int32 : _IntegerLike { }
> > 
> > extension Int64 : _IntegerLike { }
> > 
> > extension UInt32 : _IntegerLike { }
> > 
> > extension UInt64 : _IntegerLike { }
> > 
> > ```
> > 
> > If we adopted your proposed syntax below, it would take considerably more
> > 
> > lines of boilerplate code to express the same thing. The burden increases
> > 
> > significantly with the complexity of the retroactive modeling. For
> > 
> > instance, if the retroactively modeled protocol had 20 requirements and you
> > 
> > were retroactively conforming 20 types, that'd be at least 400 lines of
> > 
> > boilerplate.
> > 
> > &nbsp;&nbsp;&nbsp;Basically, the way I see it, if my class MyClass implements MyProtocol,
> > 
> > &nbsp;&nbsp;&nbsp;providing someRequiredFunc(), there’s an “ownership” chain there
> > 
> > &nbsp;&nbsp;&nbsp;(reading it backwards).
> > 
> > &nbsp;&nbsp;&nbsp;Now what happens if MyClass implements MyOtherProtocol, which also has
> > 
> > &nbsp;&nbsp;&nbsp;someRequiredFunc()? In that case, I want to MyClass as a
> > 
> > &nbsp;&nbsp;&nbsp;MyOtherProtocol and get another function pointer, which just happens to
> > 
> > &nbsp;&nbsp;&nbsp;have the same human-readable name as some other property. Just because
> > 
> > &nbsp;&nbsp;&nbsp;they have the same function signature, absolutely doesn’t mean they’re
> > 
> > &nbsp;&nbsp;&nbsp;the same thing.
> > 
> > &nbsp;&nbsp;&nbsp;Now, if we strongly bind all protocol conformances to the protocol they
> > 
> > &nbsp;&nbsp;&nbsp;implement, what happens to instance methods? They don’t belong to any
> > 
> > &nbsp;&nbsp;&nbsp;protocol, their parent is the class itself. If you have an instance
> > 
> > &nbsp;&nbsp;&nbsp;method called someRequiredFunc(), and you later add a conformance to
> > 
> > &nbsp;&nbsp;&nbsp;MyProtocol, you would need to declare that it belongs to MyProtocol. If
> > 
> > &nbsp;&nbsp;&nbsp;you don’t want it to be an API-breaking change, you have to provide a
> > 
> > &nbsp;&nbsp;&nbsp;thunk (or we could provide a shorthand syntax which emits thunks for
> > 
> > &nbsp;&nbsp;&nbsp;you) to let us know that MyClass::someRequiredFunc() is the same thing
> > 
> > &nbsp;&nbsp;&nbsp;as MyClass::MyProtocol::someRequiredFunc().
> > 
> > Your argument is that two methods with the same name should not in any way
> > 
> > conflict with each other. This is a fundamental change from the status quo.
> > 
> > If we were to take your argument to its logical conclusion, any member A of
> > 
> > a type T should be capable of being designated as the implementation of a
> > 
> > requirement B of protocol P. In the most general case, two functions A and
> > 
> > B shouldn't even need to take the same number of arguments, or arguments of
> > 
> > the same type; you should be able to supply default arguments, or even
> > 
> > write custom code that takes arguments for A and computes suitable
> > 
> > arguments for B in order to forward A to B, and the language should allow
> > 
> > you to designate A as an implementation of B. But that is simply not how
> > 
> > Swift protocols are designed.
> > 
> > &nbsp;&nbsp;&nbsp;Let’s take an example where retroactive modelling could go wrong.
> > 
> > &nbsp;&nbsp;&nbsp;You’ve got different teams working on different parts of an App, and
> > 
> > &nbsp;&nbsp;&nbsp;they’ve all got their own convention for “copy()”. Sometimes it’s a
> > 
> > &nbsp;&nbsp;&nbsp;deep-copy, sometimes a shallow-copy, sometimes it’s used in a fragile
> > 
> > &nbsp;&nbsp;&nbsp;way for a specific case, whatever. Now you want to go and clean that up
> > 
> > &nbsp;&nbsp;&nbsp;by creating a “Copyable” protocol with codified guarantees. Some
> > 
> > &nbsp;&nbsp;&nbsp;objects may already conform, others may need tweaks, and some may want
> > 
> > &nbsp;&nbsp;&nbsp;both behaviours simultaneously (preserving the old,
> > 
> > &nbsp;&nbsp;&nbsp;non-Copytable-compliant behaviour until the next API break), depending
> > 
> > &nbsp;&nbsp;&nbsp;on how you look at the object. A system like this allows all of those
> > 
> > &nbsp;&nbsp;&nbsp;different ways of looking at the object live together. You could have
> > 
> > &nbsp;&nbsp;&nbsp;the old, non-comforming API as an extension with a FIXME to delete it
> > 
> > &nbsp;&nbsp;&nbsp;for version 2.
> > 
> > Even if you design a protocol called Copyable, you still need to explicitly
> > 
> > extend concrete types in order to conform to Copyable. Swift does not
> > 
> > automagically make anything conform to your protocol. If you choose
> > 
> > \*explicitly\* to conform different types that don't guarantee the same
> > 
> > semantics, and then you erroneously assume that they all have the same
> > 
> > semantics even though you \*explicitly\* chose types that don't have the same
> > 
> > semantics, you're the one who shot yourself in the foot, so to speak. It's
> > 
> > not the fault of Swift at all.
> > 
> > &nbsp;&nbsp;&nbsp;I think it’s pretty arcane that members of a type are resolved only by
> > 
> > &nbsp;&nbsp;&nbsp;their names. If you want to provide types which allow flexible views of
> > 
> > &nbsp;&nbsp;&nbsp;data, each view of that data needs to be completely free in its
> > 
> > &nbsp;&nbsp;&nbsp;expressivity.
> > 
> > &nbsp;&nbsp;&nbsp;I would actually like to see a syntax like:
> > 
> > ```swift
> > 
> > let testObject = MyClass()
> > 
> > let testMyProto = testObject.MyProtocol // the protocol-witness table
> > 
> > for testObject as a MyProtocol.
> > 
> > testObject.MyProtocol.someRequiredFunc() // that’s one function
> > 
> > testObject.someRequiredFunc() // is a different function. May happen to
> > 
> > have the same implementation as above if MyProtocol was retroactively
> > 
> > modelled.
> > 
> > ```
> > 
> > &nbsp;&nbsp;&nbsp;I think it would fit well with the dispatch system for protocol
> > 
> > &nbsp;&nbsp;&nbsp;extensions, too. I sometimes have code like the following:
> > 
> > ```swift
> > 
> > protocol Base {}
> > 
> > protocol Derived : Base {}
> > 
> > extension Base {
> > 
> > func doSomething() { … }
> > 
> > }
> > 
> > extension Derived {
> > 
> > func doSomething() {
> > 
> > …
> > 
> > (self as Base).doSomething() // Would be better if we could say
> > 
> > “self.Base.doSomething()” to disambiguate instead of casting.
> > 
> > }
> > 
> > }
> > 
> > ```
> > 
> > This is a complete redesign of protocols in Swift. With the emphasis on
> > 
> > minimizing source-breaking changes, I doubt such a change would be in scope
> > 
> > for any phase of Swift unless you could show an overwhelming benefit.
> > 
> > &nbsp;&nbsp;&nbsp;So yeah, a big +1 to marking protocol methods with their protocol
> > 
> > &nbsp;&nbsp;&nbsp;(whatever the syntax ends up looking like), and actually I’d take it
> > 
> > &nbsp;&nbsp;&nbsp;further and bake them in to the ABI. That also makes it relevant for
> > 
> > &nbsp;&nbsp;&nbsp;Swift 4 phase 1.
> > 
> > &nbsp;&nbsp;&nbsp;Karl
> > 
> > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
> > 
> > swift-evolution mailing list
> > 
> > swift-evolution@swift.org
> > 
> > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution)
> > 
> > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_  
> > swift-evolution mailing list  
> > swift-evolution@swift.org  
> > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution)
> > 
> > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_  
> > swift-evolution mailing list  
> > swift-evolution@swift.org  
> > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution)

---

<div class="post-metadata">

**Author:** ![Boris\_Wang](https://avatars.discourse-cdn.com/v4/letter/b/8dc957/32.png) [@Boris\_Wang](https://forums.swift.org/u/Boris_Wang)\
**Post date:** [September 20, 2016, 12:15am UTC](https://forums.swift.org/t/mark-protocol-methods-with-their-protocol/4034/19 "2016-09-20T00:15:11Z")

</div>

I don't think "override" is a good idea. It's not overriding.

Protocol is not Class.

Xiaodi Wu via swift-evolution \<swift-evolution@swift.org\>于2016年9月20日  
周二08:04写道：

> **···**
>
> > I definitely think Vladimir's suggestion is a great starting point, IMO.
> > 
> > However, I think it could be improved in one key respect where previous  
> > proposals using `override` are superior. Namely, the proposed `implement`  
> > keyword adds no additional safety when a type implements a protocol  
> > requirement that doesn't have a default implementation. This is because, if  
> > there's a "near-miss" typo in the function signature, an error is already  
> > generated at compile time because the type doesn't conform to the stated  
> > protocol. Currently, the error is very unhelpful, but IMO that's a  
> > straight-up bug; improving the diagnostics for that error can be done  
> > without evolution.
> > 
> > On the other hand, if we require `implement`, the simplest use case of  
> > conforming a type to a protocol with no default implementations would take  
> > more effort but provide no benefit to justify that additional effort.  
> > Moreover (I think a core team member has expressed this more elegantly in  
> > the past), there's the philosophical point that POP represents the  
> > theoretical process by which we discover and express our discovery that  
> > certain types happen to share common semantic characteristics. In that  
> > conception of POP, it would be backwards to declare a certain member as  
> > fulfilling certain protocol requirements.
> > 
> > So, if such a source breaking change were to be in scope for Swift, I  
> > would suggest modifying Vladimir's proposal to use `override` instead and  
> > requiring the keyword only when a default implementation is being  
> > overridden. To accommodate retroactive conformance, we could either propose  
> > that `extension Foo : Bar` is automatically understood to contain members  
> > that override default implementations (as Vladimir has essentially  
> > suggested), or stipulate that we must write `extension Foo : override Bar`.  
> > This has the advantage of not introducing an additional keyword and avoids  
> > the seemingly reduplicative spelling `extension Foo : implement Bar` (for  
> > what else would an `extension Foo : Bar` reasonably do but implement the  
> > requirements of Bar?).
> > 
> > On Mon, Sep 19, 2016 at 3:10 PM, Goffredo Marocchi via swift-evolution \< \> swift-evolution@swift.org\> wrote:
> > 
> > > If Swift 4 will make it impossible to tackle this again, I do not think  
> > > discussing this can be avoided for Swift 3.1... I am afraid we are rushing  
> > > into Swift 4 a bit too quickly, but perhaps it is just silly old me :).
> > > 
> > > Sent from my iPhone
> > > 
> > > On 19 Sep 2016, at 19:18, Charles Srstka via swift-evolution \< \>\> swift-evolution@swift.org\> wrote:
> > > 
> > > On Sep 19, 2016, at 12:10 PM, Vladimir.S via swift-evolution \< \>\> swift-evolution@swift.org\> wrote:
> > > 
> > > On 17.09.2016 6:32, Xiaodi Wu via swift-evolution wrote:
> > > 
> > > Let me give a concrete example of how retroactively modeling is used.
> > > 
> > > Karl is suggesting interesting but complex and IMO too much code-breaking  
> > > idea that I don't believe can be implemented at all in a reasonable amount  
> > > of time to be a part of Swift as soon as possible, to address the discussed  
> > > issue with protocols.
> > > 
> > > I wonder what objections could be made on the solution proposed below,  
> > > which should solve a major(IMO) number of issues with protocol conformance  
> > > and introduce only 1 keyword. Such solution will make Swift better as  
> > > Protocol-Oriented language and later we can even improve it, but it can  
> > > already solve a big number of issues:
> > > 
> > > 1. As soon as possible we add 'implement' keyword which is required to  
> > > mark method/property that was defined in type or extension exactly to  
> > > conform to some protocol.
> > > 
> > > 2. The 'implement' required only at a moment of 'direct' conformance,  
> > > i.e. when you declare methods/props of the type/extension that explicitly  
> > > conformed to protocol.
> > > 
> > > 3. Retrospective conformance will not require this keyword and will work  
> > > for now just like it is working today.
> > > 
> > > 4. Later, if this will be possible at all, we can extend this model to  
> > > support separate implementation of protocols with same requirements in the  
> > > same type, explicit protocol name in implemented methods/props and  
> > > improvements for retrospective conformance. For example some variants for  
> > > \*future\* improvements:
> > > 
> > > 4.1 Different implementation for different protocols  
> > > class Foo : ProtocolA, ProtocolB {  
> > > implement(ProtocolA) func foo() {...}  
> > > implement(ProtocolB) func foo() {...}  
> > > }  
> > > class Foo : ProtocolA, ProtocolB {  
> > > implement ProtocolA {  
> > > func foo() {...}  
> > > }  
> > > implement ProtocolB {  
> > > func foo() {...}  
> > > }  
> > > }  
> > > etc
> > > 
> > > 4.2 Retrospective conformance: What is the main problem with  
> > > retrospective conformance? As I see it now(correct me, if I missing  
> > > something), the problem arises in such situation:  
> > > \* we \*expect\* that some method(s) in type will play the role of  
> > > implementation of protocol's requirements, so we retrospectively conform  
> > > that type to the protocol.  
> > > \* but protocol has default implementation for its requirements  
> > > \* and type's methods, that we \*expect\* to play roles for protocol  
> > > implementation, has different parameters or slightly different method name  
> > > at all.
> > > 
> > > I.e. when we have this set of code logic:
> > > 
> > > type T {  
> > > func foo()  
> > > }
> > > 
> > > protocol P {  
> > > func foo(x: Int)  
> > > }
> > > 
> > > extension P {  
> > > func foo(x: Int) {...}  
> > > }
> > > 
> > > extension T : P { // expect foo in T will play role of P.foo  
> > > }
> > > 
> > > I support the opinion that it is not an option to require to explicitly  
> > > list conformed methods/props in type extension for retrospective  
> > > conformance.  
> > > But I do believe we need a way to \*express our intention\* regarding the  
> > > retrospective conformance: do we expect that type already contains  
> > > implementation for some protocol's requirements OR we are aware that  
> > > protocol can have defaults for some methods and our type does not contains  
> > > some implementations.
> > > 
> > > So, the solution here IMO is some syntax to express that intention. Right  
> > > now I think that we can use current syntax "extension T : P" to keep it  
> > > working as it now works: "I'm aware of all the names, defaults etc. Treat  
> > > this as usually you did". But for example something like "extension T:  
> > > implement P {..}" or "extension T: P(implement \*) {..}" will say that we  
> > > \*expect\* that all requirements of P protocol should be implemented inside T  
> > > type. Or some syntax inside extension to specify the list of methods/props  
> > > we expect to be implemented in T. Or "extension T : P(implement foo,  
> > > bar(x:y:)) {..}".. Should be discussed.
> > > 
> > > But again, IMO this could be discussed later, after we'll have  
> > > 'implement' for most important place - in type definition for method/prop  
> > > that we created exactly for the conformed protocol.
> > > 
> > > I would be completely +1 on this.
> > > 
> > > Charles
> > > 
> > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_  
> > > swift-evolution mailing list  
> > > swift-evolution@swift.org  
> > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution)
> > > 
> > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_  
> > > swift-evolution mailing list  
> > > swift-evolution@swift.org  
> > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution)
> > 
> > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_  
> > swift-evolution mailing list  
> > swift-evolution@swift.org  
> > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution)

---

<div class="post-metadata">

**Author:** ![VladimirS](https://avatars.discourse-cdn.com/v4/letter/v/f9ae1b/32.png) [@VladimirS](https://forums.swift.org/u/VladimirS)\
**Post date:** [September 20, 2016, 1:17pm UTC](https://forums.swift.org/t/mark-protocol-methods-with-their-protocol/4034/20 "2016-09-20T13:17:08Z")

</div>

Inline..

> I definitely think Vladimir's suggestion is a great starting point, IMO.
> 
> However, I think it could be improved in one key respect where previous  
> proposals using `override` are superior. Namely, the proposed `implement`  
> keyword adds no additional safety when a type implements a protocol  
> requirement that doesn't have a default implementation. This is because, if

Yes, \*at the moment of writing\* the type's code there could be no default implementation for protocol requirement. But, \*at the moment of compilation\* such default implementation could appear.

Let's discuss such scenario in case we'll take your suggestion:

You got SomeClass.swift file, 3rd party file you don't want to change or changes are not allowed. Content:

public protocol SomeProtocol {  
&nbsp;&nbsp;func foo()  
}

public class SomeClass : SomeProtocol {  
&nbsp;&nbsp;func foo() {...} // no default implementation \*at the moment of writing\*, no need in `overload`  
}

Now, you adds SomeClass.swift file to your project and in some \*other\* file you write:

extension SomeProtocol {  
&nbsp;&nbsp;func foo() {...}  
}

As you see, you don't control the SomeClass.swift but you suggest in this case SomeClass.foo() should be defined with `override`.

With 'implement' SomeClass.foo() will be marked initially and will save us if protocol's requirement PLUS default implementation changed.

> there's a "near-miss" typo in the function signature, an error is already  
> generated at compile time because the type doesn't conform to the stated  
> protocol. Currently, the error is very unhelpful, but IMO that's a

Even, if `implement` will not add safety in case there is no default implementation of protocol's requirement \*now\*, it will add safety if you decide to add such default implementation at some point of time or in some other point of your project. And this `implement` will save us in this case, as you expresses your intention explicitly and compiler will check this.

> straight-up bug; improving the diagnostics for that error can be done  
> without evolution.
> 
> On the other hand, if we require `implement`, the simplest use case of  
> conforming a type to a protocol with no default implementations would take  
> more effort but provide no benefit to justify that additional effort.

I don't believe the requirement to add just one word `implement` on the same line with method/prop declaration would take more effort to conform to protocol. I don't see see real big difference in these lines:

class Foo : Bar {  
&nbsp;&nbsp;func foo() {...}  
}

class Foo : Bar {  
&nbsp;&nbsp;implement func foo() {...}  
}

But I see that foo is a protocol requirement and compiler will help me with this. Also this add clarity when you read some one's code.

> Moreover (I think a core team member has expressed this more elegantly in  
> the past), there's the philosophical point that POP represents the  
> theoretical process by which we discover and express our discovery that  
> certain types happen to share common semantic characteristics. In that  
> conception of POP, it would be backwards to declare a certain member as  
> fulfilling certain protocol requirements.

Well.. I do believe we need some golden middle between "theoretical process" and C++ ;-) I.e. we are discussing a real-word programming language, which we use to build low-level utils, web backend applications, macOS apps, iOS apps etc. IMO we need a balance between a shiny theory and ugly bugs we \*will\* have because this theory don't allow our compiler to help us.

Probably there is another perfect way to solve the initial problem, probably core team already invented something cool and we just don't know about this yet. But for now I think its worth to add the `implement` keyword to Swift.

> So, if such a source breaking change were to be in scope for Swift, I would  
> suggest modifying Vladimir's proposal to use `override` instead and

If the community and core team will accept the idea to mark method defined in type as protocol's requirement (without any relation to existence of default implementation) only with `override` - I think this also will be a good solution. I.e. when we see `override` in type definition, we understand that this type implements something that exists in its "super" type in wide sense i.e. in its super class or in one of its protocols.

So, personally I don't insist on `implement` word, but propose some 'marker' to mark methods in type implemented exactly as implementation for some requirement.

Probably this really could be `override` - as Swift propose itself as POP language, there should be no big difference if we override a method of super class or 'override' a method of one of protocols. Just like `override` for super class method, `override` for protocol implementation method is here just because this method \*depend\* on what is defined in conformed protocol.

But again, `override` IMO should not depend on if there is a default implementation in protocol.

> **···**
>
> On 20.09.2016 3:03, Xiaodi Wu via swift-evolution wrote:
> 
> > requiring the keyword only when a default implementation is being  
> > overridden. To accommodate retroactive conformance, we could either propose  
> > that `extension Foo : Bar` is automatically understood to contain members  
> > that override default implementations (as Vladimir has essentially  
> > suggested), or stipulate that we must write `extension Foo : override Bar`.  
> > This has the advantage of not introducing an additional keyword and avoids  
> > the seemingly reduplicative spelling `extension Foo : implement Bar` (for  
> > what else would an `extension Foo : Bar` reasonably do but implement the  
> > requirements of Bar?).
> > 
> > On Mon, Sep 19, 2016 at 3:10 PM, Goffredo Marocchi via swift-evolution \> \<swift-evolution@swift.org \<mailto:swift-evolution@swift.org\>\> wrote:
> > 
> > &nbsp;&nbsp;&nbsp;&nbsp;If Swift 4 will make it impossible to tackle this again, I do not think  
> > &nbsp;&nbsp;&nbsp;&nbsp;discussing this can be avoided for Swift 3.1... I am afraid we are  
> > &nbsp;&nbsp;&nbsp;&nbsp;rushing into Swift 4 a bit too quickly, but perhaps it is just silly  
> > &nbsp;&nbsp;&nbsp;&nbsp;old me :).
> > 
> > &nbsp;&nbsp;&nbsp;&nbsp;Sent from my iPhone
> > 
> > &nbsp;&nbsp;&nbsp;&nbsp;On 19 Sep 2016, at 19:18, Charles Srstka via swift-evolution \> \<swift-evolution@swift.org \<mailto:swift-evolution@swift.org\>\> wrote:
> > 
> > > > &nbsp;&nbsp;&nbsp;&nbsp;On Sep 19, 2016, at 12:10 PM, Vladimir.S via swift-evolution \>\>\> \<swift-evolution@swift.org \<mailto:swift-evolution@swift.org\>\> wrote:
> > > > 
> > > > &nbsp;&nbsp;&nbsp;&nbsp;On 17.09.2016 6:32, Xiaodi Wu via swift-evolution wrote:
> > > > 
> > > > > &nbsp;&nbsp;&nbsp;&nbsp;Let me give a concrete example of how retroactively modeling is used.
> > > > 
> > > > &nbsp;&nbsp;&nbsp;&nbsp;Karl is suggesting interesting but complex and IMO too much  
> > > > &nbsp;&nbsp;&nbsp;&nbsp;code-breaking idea that I don't believe can be implemented at all in  
> > > > &nbsp;&nbsp;&nbsp;&nbsp;a reasonable amount of time to be a part of Swift as soon as  
> > > > &nbsp;&nbsp;&nbsp;&nbsp;possible, to address the discussed issue with protocols.
> > > > 
> > > > &nbsp;&nbsp;&nbsp;&nbsp;I wonder what objections could be made on the solution proposed  
> > > > &nbsp;&nbsp;&nbsp;&nbsp;below, which should solve a major(IMO) number of issues with  
> > > > &nbsp;&nbsp;&nbsp;&nbsp;protocol conformance and introduce only 1 keyword. Such solution  
> > > > &nbsp;&nbsp;&nbsp;&nbsp;will make Swift better as Protocol-Oriented language and later we  
> > > > &nbsp;&nbsp;&nbsp;&nbsp;can even improve it, but it can already solve a big number of issues:
> > > > 
> > > > &nbsp;&nbsp;&nbsp;&nbsp;1. As soon as possible we add 'implement' keyword which is required  
> > > > &nbsp;&nbsp;&nbsp;&nbsp;to mark method/property that was defined in type or extension  
> > > > &nbsp;&nbsp;&nbsp;&nbsp;exactly to conform to some protocol.
> > > > 
> > > > &nbsp;&nbsp;&nbsp;&nbsp;2. The 'implement' required only at a moment of 'direct'  
> > > > &nbsp;&nbsp;&nbsp;&nbsp;conformance, i.e. when you declare methods/props of the  
> > > > &nbsp;&nbsp;&nbsp;&nbsp;type/extension that explicitly conformed to protocol.
> > > > 
> > > > &nbsp;&nbsp;&nbsp;&nbsp;3. Retrospective conformance will not require this keyword and will  
> > > > &nbsp;&nbsp;&nbsp;&nbsp;work for now just like it is working today.
> > > > 
> > > > &nbsp;&nbsp;&nbsp;&nbsp;4. Later, if this will be possible at all, we can extend this model  
> > > > &nbsp;&nbsp;&nbsp;&nbsp;to support separate implementation of protocols with same  
> > > > &nbsp;&nbsp;&nbsp;&nbsp;requirements in the same type, explicit protocol name in implemented  
> > > > &nbsp;&nbsp;&nbsp;&nbsp;methods/props and improvements for retrospective conformance. For  
> > > > &nbsp;&nbsp;&nbsp;&nbsp;example some variants for \*future\* improvements:
> > > > 
> > > > &nbsp;&nbsp;&nbsp;&nbsp;4.1 Different implementation for different protocols  
> > > > &nbsp;&nbsp;&nbsp;&nbsp;class Foo : ProtocolA, ProtocolB {  
> > > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;implement(ProtocolA) func foo() {...}  
> > > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;implement(ProtocolB) func foo() {...}  
> > > > &nbsp;&nbsp;&nbsp;&nbsp;}  
> > > > &nbsp;&nbsp;&nbsp;&nbsp;class Foo : ProtocolA, ProtocolB {  
> > > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;implement ProtocolA {  
> > > > &nbsp;&nbsp;&nbsp;&nbsp;func foo() {...}  
> > > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;}  
> > > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;implement ProtocolB {  
> > > > &nbsp;&nbsp;&nbsp;&nbsp;func foo() {...}  
> > > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;}  
> > > > &nbsp;&nbsp;&nbsp;&nbsp;}  
> > > > &nbsp;&nbsp;&nbsp;&nbsp;etc
> > > > 
> > > > &nbsp;&nbsp;&nbsp;&nbsp;4.2 Retrospective conformance: What is the main problem with  
> > > > &nbsp;&nbsp;&nbsp;&nbsp;retrospective conformance? As I see it now(correct me, if I missing  
> > > > &nbsp;&nbsp;&nbsp;&nbsp;something), the problem arises in such situation:  
> > > > &nbsp;&nbsp;&nbsp;&nbsp;\* we \*expect\* that some method(s) in type will play the role of  
> > > > &nbsp;&nbsp;&nbsp;&nbsp;implementation of protocol's requirements, so we retrospectively  
> > > > &nbsp;&nbsp;&nbsp;&nbsp;conform that type to the protocol.  
> > > > &nbsp;&nbsp;&nbsp;&nbsp;\* but protocol has default implementation for its requirements  
> > > > &nbsp;&nbsp;&nbsp;&nbsp;\* and type's methods, that we \*expect\* to play roles for protocol  
> > > > &nbsp;&nbsp;&nbsp;&nbsp;implementation, has different parameters or slightly different  
> > > > &nbsp;&nbsp;&nbsp;&nbsp;method name at all.
> > > > 
> > > > &nbsp;&nbsp;&nbsp;&nbsp;I.e. when we have this set of code logic:
> > > > 
> > > > &nbsp;&nbsp;&nbsp;&nbsp;type T {  
> > > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;func foo()  
> > > > &nbsp;&nbsp;&nbsp;&nbsp;}
> > > > 
> > > > &nbsp;&nbsp;&nbsp;&nbsp;protocol P {  
> > > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;func foo(x: Int)  
> > > > &nbsp;&nbsp;&nbsp;&nbsp;}
> > > > 
> > > > &nbsp;&nbsp;&nbsp;&nbsp;extension P {  
> > > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;func foo(x: Int) {...}  
> > > > &nbsp;&nbsp;&nbsp;&nbsp;}
> > > > 
> > > > &nbsp;&nbsp;&nbsp;&nbsp;extension T : P { // expect foo in T will play role of P.foo  
> > > > &nbsp;&nbsp;&nbsp;&nbsp;}
> > > > 
> > > > &nbsp;&nbsp;&nbsp;&nbsp;I support the opinion that it is not an option to require to  
> > > > &nbsp;&nbsp;&nbsp;&nbsp;explicitly list conformed methods/props in type extension for  
> > > > &nbsp;&nbsp;&nbsp;&nbsp;retrospective conformance.  
> > > > &nbsp;&nbsp;&nbsp;&nbsp;But I do believe we need a way to \*express our intention\* regarding  
> > > > &nbsp;&nbsp;&nbsp;&nbsp;the retrospective conformance: do we expect that type already  
> > > > &nbsp;&nbsp;&nbsp;&nbsp;contains implementation for some protocol's requirements OR we are  
> > > > &nbsp;&nbsp;&nbsp;&nbsp;aware that protocol can have defaults for some methods and our type  
> > > > &nbsp;&nbsp;&nbsp;&nbsp;does not contains some implementations.
> > > > 
> > > > &nbsp;&nbsp;&nbsp;&nbsp;So, the solution here IMO is some syntax to express that intention.  
> > > > &nbsp;&nbsp;&nbsp;&nbsp;Right now I think that we can use current syntax "extension T : P"  
> > > > &nbsp;&nbsp;&nbsp;&nbsp;to keep it working as it now works: "I'm aware of all the names,  
> > > > &nbsp;&nbsp;&nbsp;&nbsp;defaults etc. Treat this as usually you did". But for example  
> > > > &nbsp;&nbsp;&nbsp;&nbsp;something like "extension T: implement P {..}" or "extension T:  
> > > > &nbsp;&nbsp;&nbsp;&nbsp;P(implement \*) {..}" will say that we \*expect\* that all requirements  
> > > > &nbsp;&nbsp;&nbsp;&nbsp;of P protocol should be implemented inside T type. Or some syntax  
> > > > &nbsp;&nbsp;&nbsp;&nbsp;inside extension to specify the list of methods/props we expect to  
> > > > &nbsp;&nbsp;&nbsp;&nbsp;be implemented in T. Or "extension T : P(implement foo, bar(x:y:))  
> > > > &nbsp;&nbsp;&nbsp;&nbsp;{..}".. Should be discussed.
> > > > 
> > > > &nbsp;&nbsp;&nbsp;&nbsp;But again, IMO this could be discussed later, after we'll have  
> > > > &nbsp;&nbsp;&nbsp;&nbsp;'implement' for most important place - in type definition for  
> > > > &nbsp;&nbsp;&nbsp;&nbsp;method/prop that we created exactly for the conformed protocol.
> > > 
> > > &nbsp;&nbsp;&nbsp;&nbsp;I would be completely +1 on this.
> > > 
> > > &nbsp;&nbsp;&nbsp;&nbsp;Charles
> > > 
> > > &nbsp;&nbsp;&nbsp;&nbsp;\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_  
> > > &nbsp;&nbsp;&nbsp;&nbsp;swift-evolution mailing list  
> > > &nbsp;&nbsp;&nbsp;&nbsp;swift-evolution@swift.org \<mailto:swift-evolution@swift.org\>  
> > > &nbsp;&nbsp;&nbsp;&nbsp;[https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution)  
> > > &nbsp;&nbsp;&nbsp;&nbsp;\<[https://lists.swift.org/mailman/listinfo/swift-evolution&gt](https://lists.swift.org/mailman/listinfo/swift-evolution&gt);
> > 
> > &nbsp;&nbsp;&nbsp;&nbsp;\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_  
> > &nbsp;&nbsp;&nbsp;&nbsp;swift-evolution mailing list  
> > &nbsp;&nbsp;&nbsp;&nbsp;swift-evolution@swift.org \<mailto:swift-evolution@swift.org\>  
> > &nbsp;&nbsp;&nbsp;&nbsp;[https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution)  
> > &nbsp;&nbsp;&nbsp;&nbsp;\<[https://lists.swift.org/mailman/listinfo/swift-evolution&gt](https://lists.swift.org/mailman/listinfo/swift-evolution&gt);
> > 
> > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_  
> > swift-evolution mailing list  
> > swift-evolution@swift.org  
> > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution)

[Next page](https://forums.swift.org/t/mark-protocol-methods-with-their-protocol/4034.md?page=2)