Right, but if you do look it up you get a bunch of things talking about sorting words.
How about pairwiseEqual? -- Adam Kemp > On Oct 13, 2017, at 5:17 AM, Xiaodi Wu <xiaodi...@gmail.com> wrote: > > “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 >>>> Authors: Xiaodi Wu >>>> Review Manager: TBD >>>> Status: Awaiting review >>>> 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