> On 19 Feb 2017, at 16:17, David Hart via swift-evolution
> <swift-evolution@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_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
