> On Jun 16, 2016, at 10:50 AM, Matthew Johnson <[email protected]> wrote:
>
>>
>> On Jun 16, 2016, at 10:36 AM, Paul Cantrell via swift-evolution
>> <[email protected] <mailto:[email protected]>> 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
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
