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

[Adam Kemp]

> On Oct 17, 2017, at 10:00 AM, Kevin Nattinger <swift at nattinger.net> wrote:
> 
> Once we allow covariant functions to satisfy protocol requirements and have generalized existentials and recursive protocol requirements, wouldn't we be able to update thusly:
> 
> protocol Unordered {
> 	func map<T>(…) -> Any<U: Unordered where U.Element == T>
> }
> protocol Ordered: Unordered {
> 	func map<T>(…) -> Any<O: Ordered where O.Element == T>
> }
> 

Now apply that to every order-preserving function that takes a Sequence and returns another Sequence. You’ve moved the burden from users of API to implementers of API. It reminds me of the const/non-const split that C++ developers have to deal with, where a lot of functions end up being implemented twice so that you can have a const version and a non-const version (generally one just calls the other). It’s a pain. I don’t want that when working with Sequences. I don’t think it’s worth it. And FWIW, when I was programming in C# I wrote functions that took an IEnumerable<T> and return another IEnumerable<T> very often. It’s a powerful feature that would have been ruined by a change like this.

> As I've been saying all along, elementsEqual returning a functionally random result when an unordered type is involved is a problem.

In theory. Where is the evidence that this leads to a significant number of real-world bugs? All you’ve done is describe a conceptual problem, but you haven’t connected the dots to real-world problems. Again, I can point to .Net, which has a much larger community of developers who have been working with the same “problem” since version 2.0 released in 2005. If this is a significant source of bugs then there should be evidence of that. Where is that evidence?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171017/d04f8743/attachment.html>