> On Oct 17, 2017, at 11:47 AM, Michael Ilseman <milse...@apple.com> wrote: > > > >> On Oct 17, 2017, at 10:15 AM, Kevin Nattinger via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >>> Because, in my analysis, the problem is that the method is incorrectly >>> named. The problem affects all types that conform to Sequence and not just >>> Set and Dictionary; elementsEqual is a distinct function from ==, and it >>> must either continue to be distinct or cease to exist, but its name does >>> nothing to clarify any distinction. >> >> In my analysis, the problem is the method's implementation. As I see it, the >> only use for `elementsEqual` is as a replacement for `==` when two objects >> are different types (or not known to be the same)—equal elements, and IF the >> sequences have an order, in the same order. Could you provide an example >> where `elementsEqual` randomly returning either true or false depending on >> internal state alone is a legitimate and desirable result? >> > > It doesn’t randomly return true or false, it consistently returns true or > false for the *same* pair of Sequences. What *same* means, of course, is > complicated and exists at two levels (as we have two ways of talking about > *same*).
I didn't mean literally random, but the result for any two equal sets is unpredictable and depends on implementation details. > > I apologize for not reading every email in depth in this thread (they are > coming in faster than I can parse them), but let me try to present motivation > for this and hopefully provide more shared understanding. > > We have two forms of equality we’re talking about: equality of Sequence and > equality of the elements of Sequences in their respective ordering. `==` > covers the former, and I’ll use the existing (harmful) name of > `elementsEqual` for the latter. > > `==` conveys substitutability of the two Sequences. This does not necessarily > entail anything about their elements, how those elements are ordered, etc., > it just means two Sequences are substitutable. `elementsEqual` means that the > two Sequences produce substitutable elements. These are different concepts > and both are independently useful. > > Cases: > > 1. Two Sequences are substitutable and produce substitutable elements when > iterated. `==` and `elementsEqual` both return true. > > Example: Two arrays with the same elements in the same order. > > > 2. Two Sequences are substitutable, but do not produce substitutable elements > when iterated. `==` returns true, while `elementsEqual` returns false. > > Example: Two Sets that contain the same elements but in a different order. > > 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? > > > 3. Two Sequences are not substitutable, but produce substitutable elements > when iterated. `==` returns false, while `elementsEqual` returns true. > > Example: Consider two sequences that have differing identity. `==` operates > on an identity level, `elementsEqual` operates at an element level. > > Contrived Example: InfiniteMonkeys and Shakespeare both produce the same > sonnet, but they’re not substitutable for my library’s purposes. The way I see it, this is exactly the reason for this function—determining whether two objects give the same sequence without regards to their types. > > > 4. Two Sequences are not substitutable and don’t produce substitutable > elements when iterated. `==` and `elementsEqual` both return false. > > Example: `[1,2,3]` compared to `[4,5,6]` > > > It is true that situations #2 and #3 are a little harder to grok, but they > are what illustrate the subtle difference at hand. I think situation #2 is > the most confusing, and has been the primary focus of this thread as Set > exists and exhibits it. Indeed. My opinion is that #2 is not just confusing, but an entirely invalid result/state. > > > Now, onto naming. `elementsEqual` is a very poor choice of name for the > concept of equality of elements in their respective orderings, as it doesn’t > highlight the “in their respective orderings” part. `lexicographicallyEqual` > highlights the ordering much better, as “abc” is not lexicographically equal > to “cba” despite having equal elements. I think it is clearly an improvement > over the status quo. I like something a little more explicit (e.g. > `elementsOrderedEqual`), personally, but I don’t care that strongly. I’m just > glad to see `elementsEqual` getting some clarification. > > > > >>> >>> Thanks, >>> Jon >>> _______________________________________________ >>> swift-evolution mailing list >>> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >> _______________________________________________ >> swift-evolution mailing list >> swift-evolution@swift.org <mailto: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
