<div>On Wed, Oct 18, 2017 at 03:05 Martin R <<a href="mailto:martinr448@gmail.com">martinr448@gmail.com</a>> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
> On 17. Oct 2017, at 23:22, Michael Ilseman via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br>
><br>
><br>
><br>
>> On Oct 17, 2017, at 1:36 PM, Benjamin G <<a href="mailto:benjamin.garrigues@gmail.com" target="_blank">benjamin.garrigues@gmail.com</a>> wrote:<br>
>><br>
>><br>
>><br>
>> On Tue, Oct 17, 2017 at 10:25 PM, Michael Ilseman <<a href="mailto:milseman@apple.com" target="_blank">milseman@apple.com</a>> wrote:<br>
>><br>
>><br>
>>> On Oct 17, 2017, at 12:54 PM, Benjamin G <<a href="mailto:benjamin.garrigues@gmail.com" target="_blank">benjamin.garrigues@gmail.com</a>> wrote:<br>
>>><br>
>>> Thanks for the post, that's the first clear explanation i see on this thread for the concepts behind the design for Sequence.<br>
>>><br>
>>> 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.<br>
>>> There is, IMHO, a much higher chance he'll either :<br>
>>> 1/ not understand anything, or<br>
>>> 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.<br>
>>><br>
>>> 1/ is pretty harmless, but 2/ seems like a source of bug.<br>
>>><br>
>>> My personal opinion after reading all this is that we should simply change the name<br>
>><br>
>> 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.<br>
>><br>
>>> to sequentiallyEquals<br>
>><br>
>> 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.<br>
>><br>
>> 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 ??<br>
>><br>
><br>
> 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`.<br>
<br>
<br>
In the earlier post <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20171009/040428.html" rel="noreferrer" target="_blank">https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20171009/040428.html</a>, Xiaodi Wu quoted from <a href="http://en.cppreference.com/w/cpp/algorithm/lexicographical_compare" rel="noreferrer" target="_blank">http://en.cppreference.com/w/cpp/algorithm/lexicographical_compare</a> because that "defines lexicographical comparison unambiguously for C++".<br>
<br>
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.<br>
<br>
In your example, "abc" is not lexicographically equal to "cba" because "a" < "c".</blockquote><div dir="auto"><br></div><div dir="auto">Not quite. It's because "a" != "c".</div><div dir="auto"><br></div><div dir="auto">C++ `lexicographical_compare` does correspond to `lexicographicallyPrecedes` and evaluates for lexicographical less-than, but the documentation there also defines lexicographical equality, which is in terms of equivalence.</div><div dir="auto"><br></div><div dir="auto">In Swift, a type can define a notion of equivalence without defining a notion of precedence, so lexicographical equality can be evaluated even if lexicographical less-than cannot in that case.</div><div dir="auto"><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">The equivalent of `elementsEqual()` in C++ would be <a href="http://en.cppreference.com/w/cpp/algorithm/equal" rel="noreferrer" target="_blank">http://en.cppreference.com/w/cpp/algorithm/equal</a>, which has the Note<br>
<br>
std::equal should not be used to compare the ranges formed by the iterators from<br>
std::unordered_set, ... because the order in which the elements are stored in<br>
those containers may be different even if the two containers store the same elements.<br>
<br>
which is the same issue that we are talking about here.<br>
<br>
My argument against the name "lexicographicallyEquals" would be<br>
<br>
- It suggests that the elements from both sequences are compared (in iteration order) using `<` (and thus required to be Comparable).<br>
- Googling for "lexicographical comparison" leads to the above C++ reference, or to <a href="https://en.wikipedia.org/wiki/Lexicographical_order" rel="noreferrer" target="_blank">https://en.wikipedia.org/wiki/Lexicographical_order</a>. Both are about ordering sequences (words) based on the order of the underlying element type (alphabet). This does not describe what `elementsEqual()` does.<br>
<br>
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.<br>
<br>
Just my 2ct. Probably this has been said before, it is difficult to keep track of the various threads in this discussion.<br>
<br>
Regards, Martin<br>
<br>
<br>
<br>
</blockquote></div></div>