<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Oct 16, 2017, at 10:43 AM, BJ Homer via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html; charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><blockquote type="cite" class="">On Oct 16, 2017, at 8:20 AM, Thorsten Seitz via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</blockquote><div class=""><blockquote type="cite" class=""><div class=""><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><div class=""><br class=""><blockquote type="cite" class="">Am 16.10.2017 um 07:19 schrieb Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" class="">xiaodi.wu@gmail.com</a>>:</blockquote></div><div class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class="">What useful generic algorithms would this protocol support that are not already possible?</div></div></div></div></div></blockquote><div class=""><br class=""></div>It would allow expressing generic algorithms depending on an order.</div><div class=""><br class=""></div><div class="">-Thorsten</div></div></div></blockquote></div><br class=""><div class="">We can already express generic algorithms that depend on an order—any generic algorithm that works on a <font face="Courier" class="">Sequence</font> works on something that is ordered. A Swift <font face="Courier" class="">Set</font> has an undefined order right now, but a generic algorithm working on any arbitrary Sequence likely doesn’t care about <i class="">what</i> the order, just that an order exists. And a Swift <font face="Courier" class="">Set</font> does indeed have an order. If you have a generic algorithm that only works on inputs sorted in a particular manner, then you’ve likely either documented that or added a “sortedBy” parameter. Otherwise, you probably just want to be able to iterate through everything.</div><div class=""><br class=""></div><div class="">Let’s assume, though, that you wanted to write an algorithm that works only on <font face="Courier" class="">MeaningfullyOrdered</font> inputs. </div><div class=""><br class=""></div><span style="font-family: Menlo; font-size: 11px; background-color: rgb(255, 255, 255); color: rgb(186, 45, 162);" class="">func</span><span style="font-family: Menlo; font-size: 11px; background-color: rgb(255, 255, 255);" class=""> extractInfo<T: </span><span style="font-family: Menlo; font-size: 11px; background-color: rgb(255, 255, 255); color: rgb(112, 61, 170);" class="">MeaningfullyOrdered</span><span style="font-family: Menlo; font-size: 11px; background-color: rgb(255, 255, 255);" class="">>(</span><span style="font-family: Menlo; font-size: 11px; background-color: rgb(255, 255, 255); color: rgb(186, 45, 162);" class="">_</span><span style="font-family: Menlo; font-size: 11px; background-color: rgb(255, 255, 255);" class=""> input: </span><span style="font-family: Menlo; font-size: 11px; background-color: rgb(255, 255, 255); color: rgb(79, 129, 135);" class="">T</span><span style="font-family: Menlo; font-size: 11px; background-color: rgb(255, 255, 255);" class="">) {</span><span style="background-color: rgb(255, 255, 255);" class=""> </span><span style="font-family: Menlo; font-size: 11px; background-color: rgb(255, 255, 255);" class="">}</span><div class=""><div style="margin: 0px; font-stretch: normal; font-size: 11px; line-height: normal; font-family: Menlo; color: rgb(49, 89, 93); background-color: rgb(255, 255, 255);" class="">extractInfo<span style="" class="">(someArray)</span></div></div><div class=""><br class=""></div><div class="">What stops the caller from simply wrapping the Set in an Array?</div><div class=""><br class=""></div><div class=""><div style="margin: 0px; font-stretch: normal; font-size: 11px; line-height: normal; font-family: Menlo; color: rgb(49, 89, 93); background-color: rgb(255, 255, 255);" class="">extractInfo<span style="" class="">(</span><span style="color: #703daa" class="">Array</span><span style="" class="">(someSet))</span></div></div><div class=""><br class=""></div><div class="">The Array constructed here is going to reflect the arbitrary ordering provided by Set, but as far as the type system is concerned, the input is an Array, which is certainly meaningfully-ordered. Have we gained anything by requiring the caller to wrap the input in an array? </div></div></div></blockquote><div><br class=""></div>We force the user to acknowledge that the unspecified order is acceptable to them, as opposed to sorting. Much like the `uniquingKeysWith` argument on Dictionary.init(keysAndValues:uniquingKeysWith:). That one even has a sane default behavior used in many other languages (`{$1}`) and still doesn't offer that as a default; whereas a set's iteration order has no sane default. I think it would even be acceptable (or even desired) to have the set's Iterator be MeaningfullyOrdered, so the user could bypass the array and use `someSet.makeIterator()`, which would probably have little if any performance or memory overhead.</div><div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class="">We’ve made the call site a bit more awkward, and we’ve lost a bit of performance. We certainly need to be able to convert Sets in to Arrays; to eliminate that would be massively source-breaking, and it’s not clear that allowing that conversion is actively harmful, so it’s unlikely to change in Swift 5.</div><div class=""><br class=""></div><div class="">So I agree with Xiaodi; I don’t see what we would gain by splitting the protocols, other than some conceptual purity. </div></div></div></blockquote><div><br class=""></div><div>Conceptual purity is, e.g. why protocols with associated types are such a pain in the ass to work with. Sequence<Int> makes plenty of sense and is concise and clear (and used in, e.g. Java, C#), why should I spell it Any<T: Sequence where T.Iterator.Element == Int>, or whatever it ends up being. 4 years into the language and two of the majorly touted benefits of the language (protocols and generics) play so poorly with each other that it is one of if not THE major pain point in the language. All because a couple people wanted conceptual purity.</div><div><br class=""></div><div>I'm quite sure I've seen the conceptual purity argument used in favor of many other suggestions on this list, though I don't have the time to go through and find them.</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class="">Some have expressed concern over the existence of <span style="font-family: Menlo; font-size: 11px; background-color: rgb(255, 255, 255);" class="">someSet.first</span>, but even if we removed it, it would still be available as <span style="font-family: Menlo; font-size: 11px; background-color: rgb(255, 255, 255);" class="">Array(someSet).first</span><span style="background-color: rgb(255, 255, 255);" class=""><span style="font-size: 11px;" class="">. </span>And we still haven't any examples of actual algorithms that would surprise the user by behaving incorrectly when given an arbitrarily-ordered sequence, so it’s hard to make the argument that this restriction is actively harmful.</span></div></div></div></blockquote><div><br class=""></div>equalElements(), the original motivation for this proposal, is actively harmful on unordered Sequences. On any two instances of any unordered Sequence that are `==`, it could come back true or false. And adding and removing an element to one of them (so the same instance is back in the same state), could change the result. I don't think anyone new to the language would expect that. </div><div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class=""><span style="background-color: rgb(255, 255, 255);" class="">I agree that </span><font face="Menlo" class="">isOrderedEqual(to:)</font> is a better name for <font face="Menlo" class="">elementsEqual()</font></div></div></div></blockquote><div><br class=""></div><div>Much more acceptable than the proposed name.</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class=""><span style="background-color: rgb(255, 255, 255);" class=""><br class=""></span></div><div class=""><span style="background-color: rgb(255, 255, 255);" class="">-BJ</span></div></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></body></html>