> On Jun 16, 2016, at 8:29 AM, Thorsten Seitz via swift-evolution > <swift-evolution@swift.org> wrote: > > Protocols are a mechanism for deriving types from each other whereas generics > are a way to parameterize types. My point was that Swift's other way to > parameterize types, namely by associated types, is very similar to generics > with wildcards when looking a the existentials of such protocols.
This has been a point of confusion for me as well. I keep hearing that associated types are different from generic protocols, but this seems like a distinction without a difference. Suppose Swift allowed generic protocols. How would a hypothetical Collection<Foo> be different in practice from the proposed existential Any<Collection where .Element == Foo>? Yes, in the realm of type theory and compiler internals they might represented differently, sure. But in practice, in terms of what code can actually do? I know of only two differences: 1. A type can only conform to any given protocol with one set of type parameters. (Nothing can be both Collection<Foo> and Collection<Bar>.) 2. When a type conforms to Collection, it declares “associatedtype Foo” instead of “: Collection<Foo>”, and Foo can be inferred by the compiler in some circumstances. That’s handy, but it’s a syntactic difference. Is there a deeper difference I’m missing? Cheers, P
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
