[swift-evolution] [Draft] open and public protocols

[Xiaodi Wu]

On Sun, Feb 19, 2017 at 4:46 PM, Karl Wagner <razielim at gmail.com> wrote:

>
> > On 19 Feb 2017, at 23:24, Xiaodi Wu via swift-evolution <
> swift-evolution at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170219/b709f868/attachment.html>