[swift-evolution] [Draft] Rename Sequence.elementsEqual

[Michael Ilseman]

> On Oct 17, 2017, at 12:54 PM, Benjamin G <benjamin.garrigues at gmail.com> wrote:
> 
> Thanks for the post, that's the first clear explanation i see on this thread for the concepts behind the design for Sequence.
> 
> I am a bit afraid that understanding all that is a bit above what to expect the average swift developer will guess when he sees functions like "prefix / first / elementEqual (or whatever it's called)" on the Set type.
> There is, IMHO, a much higher chance he'll either : 
> 1/ not understand anything, or 
> 2/ think Sets are in fact secretely ordered sets, or start writing generic extensions above Sequence or Collection thinking those protocols are synonymous for orderer collections.
> 
> 1/ is pretty harmless, but 2/ seems like a source of bug.
> 
> My personal opinion after reading all this is that we should simply change the name

Exactly, and that’s what Xiaodi’s proposal does. Confronted with these complexities, his proposal reasons that a name change is the lessor or evils, as in the “Proposed solution” section.

> to sequentiallyEquals

Xiaodi floated “lexicographicallyEqual” which is accurate and a big improvement, and I’m liking it more and more. I floated “sequentiallyEquals”, which I’m liking less and less now. My current preference is for “elementsOrderedEqual” which I think is more descriptive but unwieldy. On the other hand, this is a far less common facility, and order matters, so maybe more verbose names are fine.

As you can tell, I’m pretty wishy-washy with names and probably should abstain from bike shedding anything important ;-)


> (just because it let people hint at where this function comes from, and not let them believe that it's something native to the Set type), and not touch anything else, until maybe we someday have a way to make everything perfect for everyone.
> 

We can ease the pain a bit. E.g. warnings/deprecation when the type is concretely known to be Set, etc. Not a general solution, but might fight some bugs.

I think that of all the dichotomies we fail to model in our protocol hierarchy, the ordered vs unordered is the least useful to accommodate. It is, however, easy and fun to bike shed.


> On Tue, Oct 17, 2017 at 8:47 PM, Michael Ilseman via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
> 
> 
>> On Oct 17, 2017, at 10:15 AM, Kevin Nattinger via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at 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 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.
> 
> 
> 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. 
> 
> 
> 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.
> 
> 
> 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 at swift.org <mailto:swift-evolution at swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
> 
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171017/6af5ff39/attachment.html>