On Sun, Feb 19, 2017 at 4:46 PM, Karl Wagner <razie...@gmail.com> wrote:
> > > On 19 Feb 2017, at 23:24, Xiaodi Wu via swift-evolution < > swift-evolution@swift.org> wrote: > > > > Sorry, I have read through this thread twice and do not understand the > point you are making. Can you explain your example once more? > > > > 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? > > > > 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. > > 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. > > That’s basically the same reasoning as having a distinction between > public/open for classes, too; It isn't. The text of the proposal spends several paragraphs motivating the distinction between public and open classes in the following way: "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." 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. 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. > > 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. > > - Karl
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution