> 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; 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
