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

[Xiaodi Wu]

On Sun, Oct 15, 2017 at 9:36 PM, Jonathan Hull <jhull at gbis.com> wrote:

> 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...
>

I'll be revising the proposal to incorporate these suggests, settling on
`elementsEqualInIterationOrder`.


> 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.
>

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.

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171016/c5f10702/attachment.html>