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

[Kevin Nattinger]

> On Oct 17, 2017, at 10:54 AM, Adam Kemp <adam_kemp at apple.com> wrote:
> 
> 
> 
>> On Oct 17, 2017, at 10:41 AM, Kevin Nattinger via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>>> On Oct 17, 2017, at 10:36 AM, Adam Kemp <adam_kemp at apple.com <mailto:adam_kemp at apple.com>> wrote:
>>> 
>>> 
>>>> On Oct 17, 2017, at 10:00 AM, Kevin Nattinger <swift at nattinger.net <mailto:swift at 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.

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