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

[Thorsten Seitz]

> Am 16.10.2017 um 22:29 schrieb Adam Kemp <adam_kemp at apple.com>:
> 
> 
> 
>> On Oct 16, 2017, at 12:35 PM, Thorsten Seitz via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>> IMHO `elementsEqual` provides a nice example for a method which only makes sense on something meaningfully ordered:
>> What is the use case for `elementsEqual` that works with a Set?
> 
> There may not be one, but here’s the problem:
> 
> 1. It’s generally useful for Set to conform to a protocol that allows you to iterate over its elements.

Absolutely. There is no dispute about that.


> 2. It’s generally useful to be able to ask if two objects that you can iterate over are equal by comparing the elements in the order that they’re iterated over.

Here I disagree. This operation only makes sense if the iteration order has underlying well defined semantics. Otherwise the result of that operation will be a random value, depending on the undefined order. I argue that this is never useful. That is why I am asking for a use case for that.


> 
> The argument being made is that these two protocols should be different, but I don’t think the proponents of that idea have fully thought through what that would mean in practice. Consider a function like map, which takes a Sequence and produces another Sequence. This function is useful for both ordered and unordered elements so it would have to be defined in terms of the looser (unordered) type, which means its output type would be unordered. Imagine starting with an ordered enumerable and calling map on it. What’s the result? An unordered enumerable (the return type of map would be unordered to match its input type).

Good point. There are several solutions for this, e.g. covariant redefinition of the result type to be ordered in an ordered subclass, or more sophisticated solutions which could even allow to chose the result type if required to be different from a default.
The latter would allow e.g. mapping over a Set to commonly result in a generic Iterable but in some cases it might also result in another Set. The same holds for mapping over an ordered collection like an Array. The result might commonly be an array but it might also be a Set or something else.
Swift currently lacks the necessary capabilities in the type system to achieve this, though, so we would have to stay with the current solution that `map` always returns an Array (at least for the moment) — which already is not very satisfactory in itself.

-Thorsten


> Now you can’t use any of the methods that require the stricter (ordered) protocol on the result, even though you haven’t actually lost the order. You would have to do something to fix up the type and make the compiler see it as ordered again. Maybe there’s an asOrdered method or something. Imagine having to sprinkle that throughout your code just to make things compile. Does that sound like a usable API?
> 
> 
> let people:[Person] = [] // Ordered
> let orderedNames:[String] = [] // Ordered
> let names = people.map { $0.fullName } // Result is unordered
> return names.elementsEqual(orderedNames) // compile error: names is unordered
> // Maybe: return names.asOrdered().elementsEqual(orderedNames)?
> 
> Avoiding this mess would require overloading such that every function that supports either ordered or unordered would have to be written both ways, which would just be a different mess.
> 
> All of that would be to solve a problem that in practice doesn’t seem to really cause any problems. I’m not aware of any evidence to suggest that this type causes a significant number of bugs, and we have another language/runtime (C#/.Net) with a large number of active developers and code bases with the same design and the same lack of evidence of a problem.
> 
> It seems like we’re being asked to make the library significantly harder to work with in order to solve a set of bugs that, as far as I can tell, doesn’t really exist in practice. I think in order to even consider this we would need to see the evidence that there’s a real problem to solve, and see a solution that didn’t make the library significantly harder to use.

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