Enhanced existential types proposal discussion


(J.E. Schotsman) #1

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

Jan E.


(Austin Zheng) #2

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.

Austin

···

On May 26, 2016, at 8:00 AM, Matthew Johnson via swift-evolution <swift-evolution@swift.org> wrote:

On May 26, 2016, at 9:54 AM, Jan E. Schotsman via swift-evolution <swift-evolution@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Matthew Johnson) #3

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!

···

On May 26, 2016, at 9:54 AM, Jan E. Schotsman via swift-evolution <swift-evolution@swift.org> wrote:

Jan E.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Matthew Johnson) #4

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 }

···

On May 26, 2016, at 10:36 AM, Austin Zheng <austinzheng@gmail.com> wrote:

Austin

On May 26, 2016, at 8:00 AM, Matthew Johnson via swift-evolution <swift-evolution@swift.org> wrote:

On May 26, 2016, at 9:54 AM, Jan E. Schotsman via swift-evolution <swift-evolution@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution