<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sun, Feb 19, 2017 at 4:46 PM, Karl Wagner <span dir="ltr"><<a href="mailto:razielim@gmail.com" target="_blank">razielim@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-"><br>
> On 19 Feb 2017, at 23:24, Xiaodi Wu via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br>
><br>
</span><span class="gmail-">> Sorry, I have read through this thread twice and do not understand the point you are making. Can you explain your example once more?<br>
><br>
> Specifically, I do not understand why it is that your code should have problems with third-party types that conform to your protocol. If your protocol has requirements that third-party types cannot fulfill, then naturally those requirements will prevent a third-party from conforming new types to your protocol. OTOH, if your protocol does not have any requirements that third-party types cannot fulfill, then your code that accepts anything that conforms to your protocol should be indifferent to whether the conforming type is defined by you or someone else. After all, a conforming type would fulfill all the semantic and syntactic requirements of the protocol! If your protocol has requirements that you are unable to state in code, causing third-party types to conform that really shouldn't, then that is a case for additional features that allow you to express those requirements more accurately, not an argument for having protocols that can't be conformed to by a third-party. What am I missing?<br>
><br>
<br>
</span>I see it as an API expressivity thing; it’s not that clients _can’t_ technically conform to the protocol, it’s that they _shouldn’t_ because that’s not why I’m exposing it.<br>
<br>
There are protocols that you do expose because you expect others to conform to them. There are others which you only expect to be used as generic/existential constraints.<br>
<br>
That’s basically the same reasoning as having a distinction between public/open for classes, too;</blockquote><div><br></div><div>It isn't. The text of the proposal spends several paragraphs motivating the distinction between public and open classes in the following way:</div><div><br></div><div>"A subclass that overrides methods of its superclass is intricately intertwined with it. The two systems are not composed, and their behavior cannot be understood independently. [...] Subclasses cannot be independently tested using a mocked implementation of the superclass or composed to apply the customizations of two different subclasses to a single instance."</div><div><br></div><div>This is in direct contradistinction to protocols. Protocols *are* meant to be composed. While a type is meant to uphold the semantic guarantees of protocols to which it conforms, the behavior of a protocol and its conforming types *are* meant to be understood independently. Conforming types *are* meant to be testable independently from the protocols to which they conform.<br><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> before we had “open” as a separate thing, you could subclass anything that was public. There was extra motivation for classes because of the opportunities for the optimiser to devirtualise function calls which may not be as strong a factor for protocols, but from an API design perspective it’s still nice to have consistent capabilities. From looking at my own code, I know that marking-up protocols which clients can conform to with @open would make both of our lives easier.<br>
<br>
I wouldn’t mind if we allowed the compiler to not enforce this rule very strongly (e.g. with a suppressible warning). Depends on what is achievable.<br>
<span class="gmail-HOEnZb"><font color="#888888"><br>
- Karl</font></span></blockquote></div><br></div></div>