<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Ok, just to summarize our options so far (in order of effort & theoretical effectiveness):<div class=""><br class=""></div><div class="">1) <b class="">Do nothing</b> - This is the easiest thing to do, but it won’t fix any problems</div><div class=""><br class=""></div><div class="">2) <b class="">Rename the elementsEqual method</b>: (Again, fairly easy to do, and will hopefully reduce confusion, but doesn’t fix the underlying issue)</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>• lexicographicallyEquals</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>• elementOrderingEqual (this is my favorite of the names)</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>• sequentiallyEquals</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>• orderedEqual</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>• pairwiseEqual</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>• iterativelyEquals</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>I might be missing some...</div><div class=""><br class=""></div><div class="">3) <b class="">Change the implementation of Set</b> so that it will return the same order whenever it has the same elements. This solves the issue with set, but not with unordered sequences in general (e.g. comparing a set with the keys of a dictionary). Still on balance, this is my current favorite.</div><div class=""><br class=""></div><div class="">4) <b class="">Add an UnorderedX</b> (name to be bikeshed) <b class="">protocol</b> <b class="">that defines a sequence/collection as unordered</b>, which provides a method which will <b class="">return a sequence/collection of defined order</b>. Generic algorithms can check for conformance to the UnorderedX protocol, and provide different implementations as needed (mostly by operating on the provided sequence/collection). The advantage is that generic algorithms can be made which take whether the sequence is ordered/unordered into account, and we don’t lose any speed. The downside is that you have to remember to check if it is ordered or not, and failing to do so may result in generic algorithms which have the current issues. We could guarantee that the standard library would be correct though.</div><div class=""><br class=""></div><div class="">5) <b class="">Add an UnorderedX</b> <b class="">protocol</b> <b class="">that defines a sequence/collection as unordered</b>, takes the unordered elements and uses them to <b class="">provide a partial implementation to Sequence/Collection</b> where the elements have a defined order. The advantage to this is that you can now build correct generic algorithms that depend on a stable/defined ordering that will “just work" (e.g. elementsEqual will work when comparing a set to the keys of a dictionary). The disadvantage is that it will be a bit slower for things that don’t care about ordering (e.g. many things involving for-in) unless you specifically call a method that says you don’t care about the order.</div><div class=""><br class=""></div><div class="">6) <b class="">Rework the Sequence protocols to account for Ordered and Unordered</b> (e.g. replacing ‘first’ with ‘any’ and then adding ‘first’ back in only for ordered sequences). Reworking the protocol hierarchy would be the most permanent and theoretically “correct” fix, but has the potential to be massively source-breaking.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">Thanks,</div><div class="">Jon</div></body></html>