> On 17. Oct 2017, at 23:22, Michael Ilseman via swift-evolution > <swift-evolution@swift.org> wrote: > > > >> On Oct 17, 2017, at 1:36 PM, Benjamin G <benjamin.garrig...@gmail.com> wrote: >> >> >> >> On Tue, Oct 17, 2017 at 10:25 PM, Michael Ilseman <milse...@apple.com> wrote: >> >> >>> On Oct 17, 2017, at 12:54 PM, Benjamin G <benjamin.garrig...@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. >> >> I'm sorry to bring more bikeshedding, but lexicographicallyEqual seems >> absolutely atrocious to me. Imagine all the steps required the user of a >> Set<Int> to understand why a lexicographicallyEqual function is suggested by >> the compiler ?? >> > > My initial resistance is that lexicographical implies a comparability beyond > equality. `lexicographicallyEquals`, then, had me (erroneously) wondering if > the “lexicographically” part meant that the elements were presented in > lexicographical order and then compared for equality. But, I was in error and > this is a wrong interpretation of the term. “abc” is not lexicographically > equal to “cba”, and it’s quite a mental leap to think that the order of > elements would be presented differently. That’s not to say that others won't > have the same misinterpretation and that’s why I’m hoping for a better name. > But, if `lexicographicallyEquals` is what we settle on, that’s a huge > improvement over `elementsEqual`.
In the earlier post https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20171009/040428.html, Xiaodi Wu quoted from http://en.cppreference.com/w/cpp/algorithm/lexicographical_compare because that "defines lexicographical comparison unambiguously for C++". But that definition corresponds to what `lexicographicallyPrecedes()` method does: two sequences are compared in iteration order using `<`, until one is exhausted or a difference is found. It requires that the sequence Element type is Comparable (but not that the sequences elements are ordered!) and allows to order all sets with the same element type. In your example, "abc" is not lexicographically equal to "cba" because "a" < "c". The equivalent of `elementsEqual()` in C++ would be http://en.cppreference.com/w/cpp/algorithm/equal, which has the Note std::equal should not be used to compare the ranges formed by the iterators from std::unordered_set, ... because the order in which the elements are stored in those containers may be different even if the two containers store the same elements. which is the same issue that we are talking about here. My argument against the name "lexicographicallyEquals" would be - It suggests that the elements from both sequences are compared (in iteration order) using `<` (and thus required to be Comparable). - Googling for "lexicographical comparison" leads to the above C++ reference, or to https://en.wikipedia.org/wiki/Lexicographical_order. Both are about ordering sequences (words) based on the order of the underlying element type (alphabet). This does not describe what `elementsEqual()` does. Both arguments are unrelated to whether the sequences are generated from ordered or unordered collections (like sets), or whether the elements in each sequence are ordered or not. Just my 2ct. Probably this has been said before, it is difficult to keep track of the various threads in this discussion. Regards, Martin _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
