[swift-evolution] [swift-evolution-announce] [Review] SE-0089: Replace protocol<P1, P2> syntax with Any<P1, P2>

[Paul Cantrell]

> On Jun 16, 2016, at 10:50 AM, Matthew Johnson <matthew at anandabits.com> wrote:
> 
>> 
>> On Jun 16, 2016, at 10:36 AM, Paul Cantrell via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>> 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>?
> 
> If Collection were a Java-like generic protocol you would have 5 generic parameters, all of which must be explicitly provided with arguments when forming an existential, although the arguments could be wildcards.  This is a bit unwieldy.

Yes. This was #2 on my list. A very, very nice syntactic difference — nonrepetition of redundant type information is so much of what makes Swift great. — but only a syntactic difference.


>> 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>.)
> 
> This is a pretty huge difference.  Multiple conformances are on the unlikely list for Swift and generic protocol syntax implies multiple conformances are possible (as is the case in at least some languages).

Right. Is that it? Are associated types really just generic protocols + single conformance constraint + type params inferred / implied?

P
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160616/fa728453/attachment.html>