“Lexicographical comparison” is a pretty standard term, and easy to Google. We didn’t make it up for Swift :)
Since Swift names this protocol Sequence, something named “Sequence.sequenceEqual” cannot distinguish this method from ==. On Fri, Oct 13, 2017 at 01:28 Adam Kemp <adam.k...@apple.com> wrote: > I agree that the proposed name is a poor choice. If we just focus on the > naming part, there is precedent in other languages for the name > “sequenceEqual”. I think that name makes it a bit clearer that the result > is whether the sequences match pair wise rather than whether they have the > same elements irrespective of order. I don’t think it entirely solves the > problem, but I like it a lot better than the proposed name. > > -- > Adam Kemp > > On Oct 12, 2017, at 9:57 PM, Kevin Nattinger via swift-evolution < > swift-evolution@swift.org> wrote: > > –∞ > > 1. I strongly object to the proposed name. It doesn't make it more clear > to me what the method does, and is misleading at best. Among other issues, > "lexicographical" is defined as alphabet order, and (1) this method applies > to objects that are not Strings, and (2) this method's behavior isn't any > more well-defined for Strings, so that name is even more of a lie than the > original. > > 2. This is really just a symptom of a bigger problem. The fact that two > Sets can compare equal and yet return different results for that method > (among too many others) is logically inconsistent and points to a much > deeper issue with Set and Sequence. It is probably about 3 releases too > late to get this straightened out properly, but I'll outline the real issue > in case someone has an idea for fixing it. > > *The root of the problem is that Set conforms to Sequence, but Sequence > doesn't require a well-defined order.* Since Set doesn't have a > well-defined order, a significant portion of its interface is unspecified. > The methods are implemented because they have to be, but they doesn't have > well-defined or necessarily consistent results. > > A sequence is, by definition, ordered. That is reflected in the fact that > over half the methods in the main Sequence definition* make no sense and > are not well-defined unless there is a well-defined order to the sequence > itself. What does it even mean to `dropFirst()` in a Set? The fact that two > objects that compare equal can give different > results for a 100% deterministic function is illogical, nonsensical, and > dangerous. > > * 7/12 by my count, ignoring `_*` funcs but including the `var` > > The current contents of Sequence can be cleanly divided into two groups; > those that return SubSequence imply a specific ordering, and the > rest do not. > > I think those should be/should have been two separate protocols: > > public protocol Iterable { > associatedtype Iterator: IteratorProtocol > func map<T>(...) -> [T] // Iterable where .Iterator.Element == T > func filter(...) -> [Iterator.Element] // Iterable where > .Iterator.Element == Self.Iterator.Element > func forEach(...) > func makeIterator() -> Iterator > var underestimatedCount: Int { get } > } > > public protocol Sequence: Iterable { // Maybe OrderedSequence just to > make the well-defined-order requirement explicit > associatedtype SubSequence > func dropFirst(...) -> SubSequence // Sequence where > .Iterator.Element == Self.Iterator.Element > func dropLast(...) -> SubSequence // " " > func drop(while...) -> SubSequence // " " > func prefix(...) -> SubSequence // " " > func prefix(while...) -> SubSequence // " " > func suffix(...) -> SubSequence // " " > func split(...where...) -> [SubSequence] // Iterable where > .Iterator.Element == (Sequence where .Iterator.Element == > Self.Iterator.Element) > } > > (The comments, of course, would be more sensible types once the ideas can > actually be expressed in Swift) > > Then unordered collections (Set and Dictionary) would just conform to > Iterable and not Sequence, so ALL the methods on those classes would make > logical sense and have well-defined behavior; no change would be > needed for ordered collections. > > Now, the practical matter. If this were Swift 1->2 or 2->3, I doubt there > would be a significant issue with actually making this change. > Unfortunately, we're well beyond that and making a change this > deep is an enormous deal. So I see two ways forward. > > 1. We could go ahead and make this separation. Although it's a potentially > large breaking change, I would argue that because the methods are > ill-defined anyway, the breakage is justified and a net benefit. > > 2. We could try and think of a way to make the distinction between ordered > and unordered "sequences" in a less-breaking manner. Unfortunately, I don't > have a good suggestion for this, but if anyone has ideas, I'm all ears. Or > eyes, as the case may be. > > > On Oct 12, 2017, at 4:24 PM, Xiaodi Wu via swift-evolution < > swift-evolution@swift.org> wrote: > > Rename Sequence.elementsEqual > > - Proposal: SE-NNNN > <https://gist.github.com/xwu/NNNN-rename-elements-equal.md> > - Authors: Xiaodi Wu <https://github.com/xwu> > - Review Manager: TBD > - Status: *Awaiting review* > > <https://gist.github.com/xwu/1f0ef4e18a7f321f22ca65a2f56772f6#introduction> > Introduction > > The current behavior of Sequence.elementsEqual is potentially confusing > to users given its name. Having surveyed the alternative solutions to this > problem, it is proposed that the method be renamed to > Sequence.lexicographicallyEquals. > [...] > > _______________________________________________ > > > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution > >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution