This makes more sense already. But in this case, wouldn't I be interested, as a
client, in creating my own TextStreams, some of which might write to a custom
log file, to a web service, etc... ?
> On 19 Feb 2017, at 17:00, Karl Wagner <razie...@gmail.com> wrote:
>
>
>> 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
