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

Thorsten Seitz tseitz42 at icloud.com
Mon Oct 16 00:11:11 CDT 2017



> Am 16.10.2017 um 04:36 schrieb Jonathan Hull via swift-evolution <swift-evolution at swift.org>:
> 
> Ok, just to summarize our options so far (in order of effort & theoretical effectiveness):
> 
> 1) Do nothing - This is the easiest thing to do, but it won’t fix any problems
> 
> 2) Rename the elementsEqual method: (Again, fairly easy to do, and will hopefully reduce confusion, but doesn’t fix the underlying issue)
> 	• lexicographicallyEquals
> 	• elementOrderingEqual (this is my favorite of the names)
> 	• sequentiallyEquals
> 	• orderedEqual
> 	• pairwiseEqual
> 	• iterativelyEquals
> 	I might be missing some...

This is just wasting time IMO. Lets tackle the real problem.

> 
> 3) Change the implementation of Set 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.
> 
> 4) Add an UnorderedX (name to be bikeshed) protocol that defines a sequence/collection as unordered, which provides a method which will return a sequence/collection of defined order. 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.
> 
> 5) Add an UnorderedX protocol that defines a sequence/collection as unordered, takes the unordered elements and uses them to provide a partial implementation to Sequence/Collection 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).  

Maybe instead of `elementsEqual` we need a `unorderedEquals` method to solve the problems `elementsEqual` was written for?


> 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.
> 
> 6) Rework the Sequence protocols to account for Ordered and Unordered (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.

This is what should be fixed IMO.

-Thorsten
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171016/e29ef7e5/attachment.html>


More information about the swift-evolution mailing list