[swift-evolution] protocol can only be used as a generic constraint because it has Self or associated type requirements

[David Waite]

> On Dec 14, 2015, at 12:37 AM, Dave Abrahams via swift-evolution <swift-evolution at swift.org> wrote:
> <snip>
> Personally, I have always thought that protocols intended to be used as unbound existentials (not P<A: Int>, just plain P) are different beasts entirely from the kind used as generic constraints and should be explicitly declared as such—I don't think I've ever seen a protocol that is well-used in both ways; if you have counterexamples I'd love to see them.  In "existential protocols," declaring an associated type or creating a self requirement would be an error at the point of declaration.  

I recently gave a talk on protocols and protocol oriented programming, and while writing it I came up with three kinds of protocols:

- Basic protocols, without type aliases or parents with type aliases, usable against any value or class type
- Objective-C protocols, without the possibility of type aliases, restricted to being implemented by Objective-C classes and supporting optional methods
- “Deferred Type” protocols, with type aliases or a parent with a type alias, where conformance is too flexible for the protocol to be used safely without the compiler knowing the implementing type. These protocols are only usable in a context where the compiler can figure out the conforming type, which it then uses statically

I lamented that protocol is used to describe the third type as well as the first two.

-DW
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151214/682103f9/attachment.html>