[Draft] Rename Sequence.elementsEqual

This matches with my first-read gut-interpretation as well. Even though this might be technically an accurate use of the word, when I read “lexicographically” that implies to me a “natural ordering of the elements", not whatever the ordering happens to be on the collection at that time, so that I would expect:

[“A”, “B”, “C”].lexographicallyEquals([“B”, “A”, “C”]) // true

Especially since the additional qualification over “equals” serves to emphasize the “lexographically” in reading the API (ie: not just “equals” but “lexographically equals”). Sure, maybe that’s a mis-reading of “lexicographically”, but it’s a pretty natural one, and a quick non-scientific poll of a few developers I work with had either a similar reading, or didn’t know what the function might mean. In either case, this naming seems contrary to the Swift API goal of “Clarity at the call site”.

So -1 from me for this name.

If we really want to rename this, what about something like:

[“A”, “B”, “C”].isOrderedEqual(to: [“B”, “A”, “C”]) // false
[“A”, “B”, “C”].isOrderedEqual(to: [“A”, “B”, “C”]) // true
[“A”, “B”, “C”].isOrderedEqual(to: [“A”, “B”, “D”]) // false

···

---

On the other hand, I’m also very much +1 for “Split Iterable out of Sequence” as soon as possible (even 4.x if possible)

Yes, this will be a breaking change. But the longer we let this obviously wrong modeling of Dictionary & Set linger, 1) the bigger a breaking change it will be, and 2) the more fundamentally unsafe code and undefined behavior will be written in Swift, directly undermining the language’s claims to safety by design.

Perhaps we could mitigate some of the breakage by retaining the “broken” interfaces on Iterable with deprecation notices, but I haven’t through that through very much.

—Karim

On Oct 13, 2017, at 5:52 PM, swift-evolution-request@swift.org wrote:

From: Christopher Whidden <christopher.whidden@gmail.com <mailto:christopher.whidden@gmail.com>>
To: Xiaodi Wu <xiaodi.wu@gmail.com <mailto:xiaodi.wu@gmail.com>>
Cc: swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>>
Subject: Re: [swift-evolution] [Draft] Rename Sequence.elementsEqual
Message-ID: <DEA22A3B-741E-4AA9-B922-7C123032B160@gmail.com <mailto:DEA22A3B-741E-4AA9-B922-7C123032B160@gmail.com>>
Content-Type: text/plain; charset="utf-8"

Using the term “lexicographically” implies to me that the Element type must conform to Comparable, as would be required for a total order. The Sequence method you mention, lexicographicallyPrecedes(_:), does have this constraint, whereas the method in question for elementsEqual(_:slight_smile: / lexicographicallyEquals(_:slight_smile: only has the constraint that the Element is Equatable. As an example, an array of simple enums has no default lexicographical ordering but is still able to use this method because enums (without associated values) are Equatable by default:

enum Foo {
   case bar
   case baz
}

let f1 = [Foo.bar, Foo.baz]
let f2 = [Foo.baz, Foo.bar]

f1.elementsEqual(f2) //false
f1.elementsEqual(f2.reversed()) //true

I also share Jonathan’s concerns that some programmers may misinterpret [lexicographically][Equals] to mean [sorted in lexicographical order][compare sequence equality], which is not what the method in question does.

Xiaodi, I think you are right that Sequence.sequentiallyEquals is to close to "==" to use, but I think we have to find something better here.

I’ll recommend that we use the name Sequence.iterativelyEquals(_:slight_smile: since this describes the body of the method concisely. A rough abbreviation of this algorithm is:

1. Iterate over elements in two sequences
  a. Compare elements for equality

“iterativelyEquals" concisely describes this.

On Oct 12, 2017, at 6:24 PM, Xiaodi Wu via swift-evolution <swift-evolution@swift.org <mailto: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.

<https://gist.github.com/xwu/1f0ef4e18a7f321f22ca65a2f56772f6#motivation>Motivation

As outlined by Ole Begemann <https://twitter.com/olebegemann/status/916291785185529857>, use of Sequence.elementsEqual(_:slight_smile: can lead to surprising results if the sequences compared are unordered:

var set1: Set<Int> = Set(1...5)
var set2: Set<Int> = Set((1...5).reversed())

set1 == set2 // true
set1.elementsEqual(set2) // false
This result does reflect the intended and documented behavior of the elementsEqual(_:slight_smile: method, which performs a lexicographical elementwise comparison. That is, the method first compares set1.first to set2.first, then (if the two elements compare equal) compares the next element stored internally in set1 to the next element stored internally in set2, and so on.

In almost all circumstances where a set is compared to another set, or a dictionary is compared to another dictionary, users should use == instead of elementsEqual(_:).

<https://gist.github.com/xwu/1f0ef4e18a7f321f22ca65a2f56772f6#proposed-solution>Proposed solution

The proposed solution is the result of an iterative process of reasoning, presented here:

The first and most obvious solution is to remove the elementsEqual(_:slight_smile: method altogether in favor of ==. This prevents its misuse. However, because elementsEqual(_:slight_smile: is a generic method on Sequence, we can use it to compare an instance of UnsafeBufferPointer<Int> to an instance of [Int]. This is a useful and non-redundant feature which would be eliminated if the method is removed altogether.

A second solution <https://github.com/apple/swift/pull/12318> is to create overloads that forbid the use of the elementsEqual(_:slight_smile: method specifically in non-generic code. This would prevent misuse in non-generic code; however, it would also forbid legitimate mixed-type comparisons in non-generic code while failing to prevent misuse in generic code. The solution also creates a difference in the behavior of generic and non-generic code calling the same method, which is potentially confusing, without solving the problem completely.

A third solution is to dramatically overhaul the protocol hierarchy for Swift sequences and collections so that unordered collections no longer have members such as first and elementsEqual(_:). However, this would be a colossal and source-breaking undertaking, and it is unlikely to be satisfactory in addressing all the axes of differences among sequence and collection types:

Finite versus infinite
Single-pass versus multi-pass
Ordered versus unordered
Lazy versus eager
Forward/bidirectional/random-access
A fourth solution is proposed here. It is predicated on the following observation:

Another method similar to elementsEqual(_:slight_smile: already exists on Sequence named lexicographicallyPrecedes(_:). Like first, elementsEqual(_:), drop(while:), and others, it relies on the internal order of elements in a manner that is not completely suitable for an unordered collection. However, like first and unlike elementsEqual(_:), this fact is called out in the name of the method; unsurprisingly, like first and unlike elementsEqual(_:), there is no evidence that lexicographicallyPrecedes(_:slight_smile: has been a pitfall for users.

This observation suggests that a major reason for confusion over elementsEqual(_:slight_smile: stems from its name. So, it is proposed that elementsEqual(_:slight_smile: should be renamed to lexicographicallyEquals(_:). The function will remain somewhat of a poor fit for unordered collections, but no more so than many other methods that cannot trivially be removed from the API of unordered collections (as discussed above). The key is that, with such a renaming, the behavior of this method will no longer be confusing.

<https://gist.github.com/xwu/1f0ef4e18a7f321f22ca65a2f56772f6#detailed-design>Detailed design

extension Sequence where Element : Equatable {
@available(*, deprecated, message: "Use '==' if possible to compare two sequences of the same type, or use 'lexicographicallyEquals' to compare two ordered sequences.")
public func elementsEqual<Other : Sequence>(
   _ other: Other
) -> Bool where Other.Element == Element {
   return lexicographicallyEquals(other)
}

public func lexicographicallyEquals<Other : Sequence>(
   _ other: Other
) -> Bool where Other.Element == Element {
   // The body of this method is unchanged.
   var iter1 = self.makeIterator()
   var iter2 = other.makeIterator()
   while true {
     switch (iter1.next(), iter2.next()) {
     case let (e1?, e2?):
       if e1 != e2 { return false }
     case (_?, nil), (nil, _?):
       return false
     case (nil, nil):
       return true
     }
   }
}
}
A parallel change will be made with respect to elementsEqual(_:by:); that is, it will be deprecated in favor of lexicographicallyEquals(_:by:).

<https://gist.github.com/xwu/1f0ef4e18a7f321f22ca65a2f56772f6#source-compatibility>Source compatibility

Existing code that uses elementsEqual will gain a deprecation warning.

<https://gist.github.com/xwu/1f0ef4e18a7f321f22ca65a2f56772f6#effect-on-abi-stability>Effect on ABI stability

None.

<https://gist.github.com/xwu/1f0ef4e18a7f321f22ca65a2f56772f6#effect-on-api-resilience>Effect on API resilience

This proposal adds new methods to the public API of Sequence and conforming types.

<https://gist.github.com/xwu/1f0ef4e18a7f321f22ca65a2f56772f6#alternatives-considered>Alternatives considered

It is to be noted that lexicographicallyPrecedes(_:by:) and elementsEqual(_:by:) are essentially the same method, since both perform a lexicographical comparison using a custom predicate. However, there is not a good unifying name. (lexicographicallyCompares(to:by:) reads poorly.) Moreover, the predicate supplied is intended to have very different semantics, and maintaining two distinct methods may be a superior fit with the typical user's mental model of the intended behavior and may also be clearer to readers of the code. Therefore, this proposal does not seek to unify the two methods; instead, elementsEqual(_:by:) will be renamed lexicographicallyEquals(_:by:) as detailed above.

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution