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_k...@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 <tseit...@icloud.com> wrote:
>>>
>>>
>>>> Am 18.10.2017 um 22:04 schrieb Adam Kemp <adam_k...@apple.com>:
>>>>
>>>>
>>>> On Oct 18, 2017, at 12:25 PM, Thorsten Seitz via swift-evolution
>>>> <swift-evolution@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
>
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
