> Am 16.10.2017 um 04:36 schrieb Jonathan Hull via swift-evolution 
> <swift-evolution@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
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Reply via email to