Isn't this reasoning why Sequence.allSatisfy returns true on empty sequences? (The method doesn't match on 100% success, but 0% failure.)
1 Like
(Kind of crazy how it started out just being a toy implementation for void equatable...)
2 Likes
I was sure I had seen this somewhere in the PR comments, but I couldn't find it. Turns out it was in the comments that Github had collapsed 
Just to clarify: I am not sure what the status of this pitch is. In Xcode 12.5 I get the following results:
func test() {
let points = [(x: 128, y: 316), (x: 0, y: 0), (x: 100, y: 42)]
let origin = (x: 0, y: 0)
let hashValue = origin.hashValue // ERROR: Value of optional type '(x: Int, y: Int)?' must be unwrapped to a value of type '(x: Int, y: Int)'
if origin == (0, 0) {} // works
if points.first! == (0, 0) {} // works
if points.first == (0, 0) {} // ERROR: Value of optional type '(x: Int, y: Int)?' must be unwrapped to a value of type '(x: Int, y: Int)'
if points.contains(a) {} // ERROR: Type '(x: Int, y: Int)' cannot conform to 'Equatable'
}
struct Restaurant {
let name: String
let location: (latitude: Int, longitude: Int)
}
extension Restaurant: Equatable {} // ERROR: Type 'Restaurant' does not conform to protocol 'Equatable'
Is the above errors out of scope for this proposal or is it just not implemented in Xcode 12.5? If not implemented, which of the above is out of scope?
The author of the proposal has re-implemented this feature to prevent the usage of assembly to create conformance data structures and thus not merged into main repo yet.
Not sure whether it will be part of swift@5.5.
5 Likes
As of Dec 31, 2021 it might be belated to say the followings:
But I'm also eager to this proposal because I have had to create the following structure as needed:
for example, every time I need a 2D indices structure I created the following:
/// 2D indices in place of (i:Int, j:Int) tuple.
fileprivate struct TD<Valuei:Hashable & Equatable & Comparable, Valuej:Hashable & Equatable & Comparable>: Hashable, Equatable, CustomStringConvertible {
let i: Valuei
let j: Valuej
func hash(into hasher: inout Hasher) {
hasher.combine(i)
hasher.combine(j)
}
static func ==(l: TD, r: TD) -> Bool {
l.i == r.i && l.j == r.j
}
var description: String {
"\(i),\(j)"
}
}
instead of using a plain tuple that is what I wanted.
And I could confirm what was wrong with this amazing tuples after the testing the following:
func test_the_reason_behind_why_tuple_can_not_be_hashable() {
/// ** CAVEAT **
/// Because the following is NOT possible, for tuples are not hashable.
/// var adj = [(Int,Int):[(Int,Int)]]()
///
/// By the following reason, tuples can NOT be hashable.
var c = (x: 12, y: 34)
let d = (y: 12, x: 34)
print(c == d) // true
/// **WARNING**: Expression shuffles the elements of this tuple; this behavior is deprecated
c = d
print(c == d, terminator: "\n\n") // false
}
I hope that this proposal can be accepted by the owner or the core team, even if the core team have to suppress the expression shuffling feature and invent another way to the code compatibility of old Swift versions. Because I think that it is more profitable for Swift community in the long run.
I had this in my mind for a long time, and I'm writing this to encourage Alejandro in good will.
Thank you all who participate in this thread.
Did this ever get a go ahead? I mean I still can't use tuples as Dictionary keys / Set elements. However, I believe tuples (of hashable data types) should be made hashable at least.
var seen: Set<(Int, Int)> = [(1, 2), (0, 0), (4, 3)]
// error: type '(Int, Int)' does not conform to protocol 'Hashable'
This error here is one such case where I don't feel to use Swift for Competitive Programming; isn't it tedious to declare a struct and then access the values as s.x s.y ? I think it's very common to have Tuples as hashable.
6 Likes