> Am 16.10.2017 um 04:36 schrieb Jonathan Hull via swift-evolution
> <[email protected]>:
>
> 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
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
