<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Oct 17, 2017, at 1:36 PM, Benjamin G <<a href="mailto:benjamin.garrigues@gmail.com" class="">benjamin.garrigues@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><br class="Apple-interchange-newline"><br 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="gmail_quote" 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;">On Tue, Oct 17, 2017 at 10:25 PM, Michael Ilseman<span class="Apple-converted-space"> </span><span dir="ltr" class=""><<a href="mailto:milseman@apple.com" target="_blank" class="">milseman@apple.com</a>></span><span class="Apple-converted-space"> </span>wrote:<br class=""><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); padding-left: 1ex;"><div style="word-wrap: break-word; line-break: after-white-space;" class=""><br class=""><div class=""><span class=""><br class=""><blockquote type="cite" class=""><div class="">On Oct 17, 2017, at 12:54 PM, Benjamin G <<a href="mailto:benjamin.garrigues@gmail.com" target="_blank" class="">benjamin.garrigues@gmail.com</a>> wrote:</div><br class="m_1049180946288009868Apple-interchange-newline"><div class=""><div dir="ltr" class="">Thanks for the post, that's the first clear explanation i see on this thread for the concepts behind the design for Sequence.<div class=""><br class=""></div><div class="">I am a bit afraid that understanding all that is a bit above what to expect the average swift developer will guess when he sees functions like "prefix / first / elementEqual (or whatever it's called)" on the Set type.</div><div class="">There is, IMHO, a much higher chance he'll either : </div><div class="">1/ not understand anything, or </div><div class="">2/ think Sets are in fact secretely ordered sets, or start writing generic extensions above Sequence or Collection thinking those protocols are synonymous for orderer collections.<br class=""><div class=""><br class=""></div><div class="">1/ is pretty harmless, but 2/ seems like a source of bug.</div><div class=""><br class=""></div><div class="">My personal opinion after reading all this is that we should simply change the name</div></div></div></div></blockquote><div class=""><br class=""></div></span><div class="">Exactly, and that’s what Xiaodi’s proposal does. Confronted with these complexities, his proposal reasons that a name change is the lessor or evils, as in the “Proposed solution” section.</div><div class=""><br class=""></div><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><div class="">to sequentiallyEquals</div></div></div></div></blockquote><div class=""><br class=""></div><div class=""><div class="">Xiaodi floated “lexicographicallyEqual” which is accurate and a big improvement, and I’m liking it more and more. I floated “sequentiallyEquals”, which I’m liking less and less now. My current preference is for “elementsOrderedEqual” which I think is more descriptive but unwieldy. On the other hand, this is a far less common facility, and order matters, so maybe more verbose names are fine.</div></div></div></div></blockquote><div class=""><br class=""></div><div class="">I'm sorry to bring more bikeshedding, but lexicographicallyEqual seems absolutely atrocious to me. Imagine all the steps required the user of a Set<Int> to understand why a lexicographicallyEqual function is suggested by the compiler ??</div><div class=""><br class=""></div></div></div></blockquote><div><br class=""></div><div>My initial resistance is that lexicographical implies a comparability beyond equality. `lexicographicallyEquals`, then, had me (erroneously) wondering if the “lexicographically” part meant that the elements were presented in lexicographical order and then compared for equality. But, I was in error and this is a wrong interpretation of the term. “abc” is not lexicographically equal to “cba”, and it’s quite a mental leap to think that the order of elements would be presented differently. That’s not to say that others won't have the same misinterpretation and that’s why I’m hoping for a better name. But, if `lexicographicallyEquals` is what we settle on, that’s a huge improvement over `elementsEqual`.</div><div><br class=""></div><blockquote type="cite" class=""><div class=""><div class="gmail_quote" 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;"><div class="">Since you seem to give the kind of answer i'm looking for, do you have any answer to a previous question i asked regarding the rational for conflating the iterator with the collection ?</div><div class="">What i mean by that is : i think nobody would have cared if the syntax for Set was actually</div><div class="">set1.iterator.elementEquals(set2.iterator)</div><div class="">It's a bit more verbose, but the meaning is obvious.</div></div></div></blockquote><div><br class=""></div><div>To me that reads as meaning something more akin to set1.first == set2.first (whether nil or not). I think what you’re trying to demonstrate is an equality on an iterator that implies equality of iterated elements. But, there could be alternatives: if a Sequence has identity, then perhaps its iterator’s equality should enforce the identity. I may also be completing misunderstanding your question.</div><br class=""><blockquote type="cite" class=""><div class=""><div class="gmail_quote" 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;"><div class="">I think a reason why people are confused is that the actual design conflates methods of the "iterator" on the collection type itself. An alternate design would have been to make collection Sequence<i style="font-weight: bold;" class="">able<span class="Apple-converted-space"> </span></i>rather than a sequence themselves. But i suppose you've thought about that already, so i'm just curious to know what made you choose the current solution instead.</div></div></div></blockquote></div><br class=""><div class="">No, I have not thought about it much. I’m a relatively new contributor (a few months) to the standard library, and am just now thinking about such things on an as-needed basis.</div><div class=""><br class=""></div><div class="">Personally, I care much more about what operations a data structure provides and how it does it than whatever protocol hierarchy it models. As far as what hierarchy should exist in the standard library, I care much more about pragmatism than purity as the hierarchy’s main benefit is to enable generic programming. I think George Box said it best: “All models are wrong, but some are useful”.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div></body></html>