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

[Thorsten Seitz]

In your earlier emails you wrote

"To make it concrete, say you write a function that just wraps map:
func firstNames(ofPeople people: Sequence<Person>) -> Sequence<Person> { return people.map { $0.firstName } } 
 I want that function to work on both ordered and unordered Sequences, and if you start with an ordered Sequence you should end up with an ordered Sequence. How do I make that work?"
Your example _won't work even today_ as `map` _returns an Array_ and _not_ a Sequence, like I have written several times now including in the very email you have been answering.
So you would just write the method with the most general argument type which is required by the method:

func firstNames(ofPeople people: Iterable<Person>) -> [String] {
    return people.map { $0.firstName }
}

The return type would still be Array _just like today_.

-Thorsten


> Am 19.10.2017 um 01:30 schrieb Adam Kemp <adam_kemp at apple.com>:
> 
> Please re-read my earlier emails with concrete examples of problems this split would cause:
> 
> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20171016/040501.html
> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20171016/040540.html
> 
> You’re not thinking far enough ahead about the consequences of this change. It’s not just about map, and it’s not even just about the functions that already exist today. It’s about all of the future functions that you and I and every other Swift developer is going to write dealing with Sequences. Think about the impact on those functions.
> 
> I’ve written many functions in C# that fit this pattern, and if C# had split IEnumerable in the same way you propose then my job would have been much harder.
> 
>>> On Oct 18, 2017, at 4:14 PM, Thorsten Seitz <tseitz42 at icloud.com> wrote:
>>> 
>>> 
>>>> Am 18.10.2017 um 22:04 schrieb Adam Kemp <adam_kemp at apple.com>:
>>>> 
>>>> 
>>>> On Oct 18, 2017, at 12:25 PM, Thorsten Seitz via swift-evolution <swift-evolution at swift.org> wrote:
>>>> 
>>>> Therefore having `elementsEqual` as API for unordered collections is a source of bugs …
>>> 
>>> You keep saying that, and yet after repeated requests to provide evidence you still have not backed up this claim. How many bugs are caused by this? Hypotheticals are not evidence. Show us how much of a problem this is in the real world. Why do you think this is so important to fix? What impact is it going to have? If it weren’t for this thread would you even know the problem existed?
>>> 
>>>> Adam expressed the concern that this required `map` to implemented separately for the split APIs: `Iterable.map` would have to return an `Iterable` whereas `Sequence.map` would have to return a `Sequence`. 
>>>> This is an independent issue IMO, because currently we have a similar situation: `Collection.map` does not return a `Collection` either. It returns an Array. This is a compromise partly due to missing language features which can simply remain when `Sequence` is split.
>>> 
>>> That description does not come close to showing the magnitude of the problem with this approach. The reason you think it’s not a significant problem is that you’re only looking at a single function (map). This problem isn’t specific to just one function, though. The problem is that every single function that takes in one Sequence and returns another Sequence would have to handle this distinction, including functions that you and I will want to write and reuse. That means either:
>>> 
>>> 1. Implement the function twice to handle either ordered or unordered.
>>> 2. Only handle one type.
>>> 3. Implement a complex new language feature that makes #1 slightly easier, but still harder than it is today.
>>> 
>>> That’s not an improvement. It’s a huge regression in usability. To make that kind of change should require a much stronger argument than “hypothetically this could lead to bugs”.
>> 
>> Is it really such a huge regression? You already have to decide whether to use `Sequence` or `Collection` or `BiDirectionalCollection` etc. Or maybe just `Array` or `Set` or `Dictionary`.
>> 
>> Most such functions (like map, flatMap, filter) currently return `Array`. These will not be better or worse than before.
>> 
>> For example, `dictionary.map(f)` will result in an `Array` instead of a `Dictionary` where just the values have been replaced. You see, the problem already exists.
>> 
>> For functions that do not change the element type we can use existing language features like associated types as it is already done with `SubSequence`.
>> 
>> -Thorsten
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171019/1c9197c5/attachment.html>