So, what I'm getting from this explanation is that `Equatable` is meaningless on its own; each class needs to document exactly what "substitutability" means as implemented, and any code that uses `==` needs to check the documentation for that specific class and make sure the intended use ("context," as you say) aligns with the class's definition.
>>> >>> Contrived Example: Two Lorem Ipsum generators are the same generator >>> (referentially equal, substitutable for the purposes of my library), but >>> they sample the user’s current battery level (global state) each time they >>> produce text to decide how fancy to make the faux Latin. They’re >>> substitutable, but don’t generate the same sequence. >> >> Evidently I disagree with your definition of "substitutable." How can you >> say one thing can be substituted for another when doing so gives a different >> result? >> > > They are substitutable for the purposes of certain operations. The key > question is “what” gives a different result. > > Sets are primarily about membership, and equal sets are substitutable (hand > wavy) for Set-like purposes. But, two equal Sets are not substitutable for > iteration purposes unless they produce the same elements in the same order. > This latter requirement is far less important than the former for Sets, but > can still come up in generic contexts. > > Two Lorem Ipsum generators could be equal in that they are substitutable for > (hand wavy) faux-Latin generation purposes, even if the sequence of generated > characters happens to differ. Hmm, I… guess I could see randomized generators comparing == because their public configuration is the same, just not the implementation detail of their RNG states. Not sure I'd implement it that way myself—perhaps I just take the "substitutability" more seriously than some.
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution