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...
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). 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.
Thanks,
Jon_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
