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

[Kevin Nattinger]

> On Oct 17, 2017, at 10:36 AM, Adam Kemp <adam_kemp at apple.com> wrote:
> 
> 
>> On Oct 17, 2017, at 10:00 AM, Kevin Nattinger <swift at nattinger.net <mailto: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.

The idea is that covariance would mean you only need to implement the function once.

> 
>> 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?

If there are no real-world problems, why do we feel the need to change the function name in the first place?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171017/d3dbe5eb/attachment.html>