> On Oct 17, 2017, at 10:54 AM, Adam Kemp <adam_k...@apple.com> wrote:
>
>
>
>> On Oct 17, 2017, at 10:41 AM, Kevin Nattinger via swift-evolution
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>
>>> On Oct 17, 2017, at 10:36 AM, Adam Kemp <adam_k...@apple.com
>>> <mailto:adam_k...@apple.com>> wrote:
>>>
>>>
>>>> On Oct 17, 2017, at 10:00 AM, Kevin Nattinger <sw...@nattinger.net
>>>> <mailto: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.
>>
>> The idea is that covariance would mean you only need to implement the
>> function once.
>
> In the example you showed above map is written twice. Maybe the two protocols
> can share an implementation, but you still have to have two versions declared
> somewhere.
Perhaps I'm wrong, but (once we allow covariant conformance) wouldn't a single
implementation of the `Ordered` version be covariant and thus satisfy the
`Unordered` requirement without even having a dummy implementation forwarding
to it? That's what I'm aiming for.
>
> What does it look like if you’re just writing a single function somewhere
> that takes in a Sequence and returns another Sequence? How do you make that
> function take both ordered and unordered Sequences? 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 }
> }
Hmm, I'm not sure that would work with the covariant requirement. The
associated type one could:
func firstNames<U: Unordered>(ofPeople people: U<MapResultType: Person>) ->
U.MapResultType<Element: String> {
return people.map { $0.firstName }
}
If the sequence you put in maps to an ordered sequence, you get the ordered
sequence out.
That said, I can see how the generics there could get out-of-hand as you add
more operations… -> U.MapResultType.FilterResultType.MapResultType…<Element:
String>
I'm planning on playing with this all before opening a real proposal, if/when I
can figure out how, so I'm sure I'll have to deal with these and similar
issues. Definitely good things to keep an eye out for, thanks.
>
> 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?
>
>> If there are no real-world problems, why do we feel the need to change the
>> function name in the first place?
>
> To quote myself from an earlier email: "I’m not even sure a name change is
> necessary for this method at all, but I’m not at all in favor of anything
> beyond that.”
>
> To extend that, I’m content with doing nothing. I’m not sure there’s cause
> for doing anything at all, and I’m very sure that no one on this list has
> demonstrated any need for a major change to the library, let alone new
> language features.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
