On Sun, Oct 15, 2017 at 9:36 PM, Jonathan Hull <[email protected]> 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 >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
