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

[Karl Wagner]

> On 19 Feb 2017, at 16:17, David Hart via swift-evolution <swift-evolution at swift.org> wrote:
> 
> I still don't see the use case for this. Perhaps I'm wrong, but if an API creates a protocol for the sole purpose of representing a set of concrete types, that looks more to me like bad API design, and not a missing feature in the language. Can you give me a small concrete real-world example of an API which requires that? 


Whether or not a protocol is open is also a part of API expressivity; often a library will want to expose a protocol only as a way to enable generic/existential programming over a fixed set of types, without intending that any clients add new conformers. Protocols are crucial to expressing the shared patterns amongst the set of types.

For example, I might have a TextStream protocol:

public protocol TextStream {
    func write(_: String)
}

And I might decide to expose a property as type “TextStream” purely because I reserve the right to change the underlying concrete type. I want clients to work on the protocol-existential level.

public class Component {
    var debugWriter: TextStream
}

By doing that, the underlying concrete type is no longer part of my API or ABI. I can change it between versions without breaking clients, but it’s not meaningful for any clients to create their own TextStreams; that’s not part of what my library does/allows.

- Karl
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170219/b4443546/attachment.html>