Not sure what you’re asking. Equatable is a protocol.
that's the point. i mean, if user writes this:
extension (Equatable, Equatable) : Equatable
what *else* could he mean other than this:
extension <T: Equatable, R: Equatable> (T, R) : Equatable
No, it would mean extending the concrete type `(Equatable, Equatable)`
(which has other roadblocks to becoming possible because Equatable has Self
requirements).
and if it is indeed the only reasonable meaning we can think of - i'd say
the first notation is nicer.
For a protocol P, (P, P) is a concrete type with two elements each of
existential type P.
this part i do not understand. protocol is not an existential type. or is
it?
Ah. You seem to be unfamiliar with protocol existentials. Protocols
(currently, only those without Self or associated type requirements, for
various implementation reasons) are themselves types. For example, you can
write:
protocol P { }
extension Int : P { }
let x: P = 42
In this example, x is of type `P`, not of type `Int`. Let's clarify the
difference:
extension Array where Element == P {
func hi() {
print("Hello")
}
}
extension Array where Element : P {
func hi() {
print("World!")
}
}
let y: [P] = [x]
let z: [Int] = [x as Int]
y.hi() // Prints "Hello"
z.hi() // Prints "World!"
Moreover, if we do not write the first `extension Array`, then `y.hi()`
doesn't compile. This helps to illustrate that P does not conform to itself.
For a type T : P, a tuple of type (T, T) is not a tuple of type (P, P). If
···
On Sat, Nov 25, 2017 at 5:21 PM, Mike Kluev <mike.kluev@gmail.com> wrote:
On 25 November 2017 at 23:07, Xiaodi Wu <xiaodi.wu@gmail.com> wrote:
we can extend tuples, you can write a generic algorithm that works with any
type (T, T) where T : P, and/or you can write an algorithm that works with
concrete type (P, P). Note that there is no overlap between these two
because existential type P does not conform to protocol P.
Mike
