<div dir="ltr">On Sun, Oct 15, 2017 at 8:35 PM, Jonathan Hull <span dir="ltr">&lt;<a href="mailto:jhull@gbis.com" target="_blank">jhull@gbis.com</a>&gt;</span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><span class=""><br><div><blockquote type="cite"><div>On Oct 15, 2017, at 3:41 PM, Xiaodi Wu via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt; wrote:</div><br class="m_3387007895337920158Apple-interchange-newline"><div><blockquote 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;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"><div><div>I’ll have to mull this over to see if I can come up with a coherent and (more) specific requirement for what makes an Iterable a Sequence, since clearly “documented” isn’t enough.  Perhaps something along the lines that any two Sequences that compare equal must iterate the same.</div><br><blockquote type="cite"><div><div dir="ltr" style="text-align:start;text-indent:0px"><div class="gmail_extra"><div class="gmail_quote"><div><font color="#00afcd">[…]</font></div><span><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-transform:none;white-space:normal;word-spacing:0px">Apple documentation calls this one of the &quot;order-dependent&quot; methods. It is surely acceptable for a type that conforms to an order-dependent protocol to have methods that are order-dependent; they do, however, have to be clearly order-dependent to avoid confusion on unordered types.</div></span></div></div></div></div></blockquote><div><br></div><div>I’m not clear on what you’re trying to get across here. It seems you’re saying unordered types shouldn’t have order-dependent methods, which is exactly what I’ve been arguing.</div></div></div></blockquote><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"><br></div><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">No, I&#39;m saying, essentially, that there are no truly unordered types in Swift; `Set` and `Dictionary` lead double lives modeling unordered collections on the one hand and ordered collections on the other. The order-dependent methods can continue to exist; they just need to be clearly named so that users know when they&#39;re using an instance of `Set` in the manner of an unordered collection and when they&#39;re using an instance of `Set` in the manner of an ordered collection.</div></div></blockquote></div><br></span><div>Is the order of elements returned from Set/Dictionary guaranteed not to change based on implementation?  For instance, the elements of a dictionary may shift around as I add items, and they may be different in different runs of a program.</div><div><br></div><div>If we document/say that Set will always return elements in the order they were added, then it may prevent us from using a more efficient implementation of Sets in a future version of Swift.</div><div><br></div><div>Just to check what we are saying.  I am saying that we can’t really build generic algorithms on something which is undefined (because we are leaking implementation details, and depending on private implementation details leads to problems).  You are saying that the leaking of implementation details is a feature, not a bug… and that we should just document them and consider them fixed ABI?</div></div></blockquote><div><br></div><div>We can also document the iteration order as arbitrary (i.e., the status quo).</div><div><br></div></div></div></div>