<div dir="ltr">On Sun, Oct 15, 2017 at 9:36 PM, Jonathan Hull <span dir="ltr">&lt;<a href="mailto:jhull@gbis.com" target="_blank">jhull@gbis.com</a>&gt;</span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">Ok, just to summarize our options so far (in order of effort &amp; theoretical effectiveness):<div><br></div><div>1) <b>Do nothing</b> - This is the easiest thing to do, but it won’t fix any problems</div><div><br></div><div>2) <b>Rename the elementsEqual method</b>: (Again, fairly easy to do, and will hopefully reduce confusion, but doesn’t fix the underlying issue)</div><div><span class="m_6040603840853926367Apple-tab-span" style="white-space:pre-wrap">        </span>• lexicographicallyEquals</div><div><span class="m_6040603840853926367Apple-tab-span" style="white-space:pre-wrap">        </span>• elementOrderingEqual (this is my favorite of the names)</div><div><span class="m_6040603840853926367Apple-tab-span" style="white-space:pre-wrap">        </span>• sequentiallyEquals</div><div><span class="m_6040603840853926367Apple-tab-span" style="white-space:pre-wrap">        </span>• orderedEqual</div><div><span class="m_6040603840853926367Apple-tab-span" style="white-space:pre-wrap">        </span>• pairwiseEqual</div><div><span class="m_6040603840853926367Apple-tab-span" style="white-space:pre-wrap">        </span>• iterativelyEquals</div><div><span class="m_6040603840853926367Apple-tab-span" style="white-space:pre-wrap">        </span>I might be missing some...</div></div></blockquote><div><br></div><div>I&#39;ll be revising the proposal to incorporate these suggests, settling on `elementsEqualInIterationOrder`.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div></div><div>3) <b>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></blockquote><div><br></div><div>As I mentioned earlier, I think 4-6 are wildly out of the scope of this discussion. The starting premise is that Set : Collection and Sequence : Collection, and that this will not change for Swift 5.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div></div><div>4) <b>Add an UnorderedX</b> (name to be bikeshed) <b>protocol</b> <b>that defines a sequence/collection as unordered</b>, which provides a method which will <b>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><br></div><div>5) <b>Add an UnorderedX</b> <b>protocol</b> <b>that defines a sequence/collection as unordered</b>, takes the unordered elements and uses them to <b>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&quot; (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><br></div><div>6) <b>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><br></div><div><br></div><div>Thanks,</div><div>Jon</div></div></blockquote></div><br></div></div>