> On May 26, 2016, at 10:36 AM, Austin Zheng <[email protected]> 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
>> <[email protected]> wrote:
>>
>>
>>> On May 26, 2016, at 9:54 AM, Jan E. Schotsman via swift-evolution
>>> <[email protected]> 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
>>> [email protected]
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>> _______________________________________________
>> swift-evolution mailing list
>> [email protected]
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
