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
