[swift-evolution] Enhanced existential types proposal discussion

[Matthew Johnson]

> On May 26, 2016, at 10:36 AM, Austin Zheng <austinzheng at gmail.com> wrote:
> 
> Yes, that's definitely an oversight. 
> 
> That being said, the example is also actually incorrect, because AFAIK it's not possible to conform a type T to multiple protocols A and B, and have A.Element and B.Element be different types (i.e. the constraint is redundant). So it should be rewritten as well.

It isn’t possible today, but there has already been discussion about introducing a mechanism to allow users to resolve the ambiguity when conforming:

protocol P { associatedtype Element }
struct S: P { typealias P.Element = Foo }

> 
> Austin
> 
>> On May 26, 2016, at 8:00 AM, Matthew Johnson via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>> 
>>> On May 26, 2016, at 9:54 AM, Jan E. Schotsman via swift-evolution <swift-evolution at swift.org> wrote:
>>> 
>>> In the "where clause" section, shouldn't this be allowed:
>>> 
>>> let a : Any<Collection, SetAlgebraType where Collection.Element == SetAlgebraType.Element>
>>> 
>>> I am asking because the acceptable type equality constraint is stated as:
>>> 
>>> Type equality constraint: X == ConcreteType
>> 
>> Yes, you should definitely be able to equate two associate types!  If the proposal isn’t clear about that it is probably just an oversight.  Good catch!
>> 
>>> 
>>> Jan E.
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>