> On Oct 17, 2017, at 10:00 AM, Kevin Nattinger <sw...@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?
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
