<div dir="ltr">On Wed, Oct 25, 2017 at 12:06 PM, David Zarzycki <span dir="ltr">&lt;<a href="mailto:dave@znu.io" target="_blank">dave@znu.io</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;line-break:after-white-space"><br><div><span class=""><br><blockquote type="cite"><div>On Oct 25, 2017, at 12:01, David Sweeris &lt;<a href="mailto:davesweeris@mac.com" target="_blank">davesweeris@mac.com</a>&gt; wrote:</div><br class="m_4899158335981833298Apple-interchange-newline"><div><div style="word-wrap:break-word"><br><div><blockquote type="cite"><div>On Oct 25, 2017, at 5:29 AM, David Zarzycki via swift-dev &lt;<a href="mailto:swift-dev@swift.org" target="_blank">swift-dev@swift.org</a>&gt; wrote:</div><br class="m_4899158335981833298Apple-interchange-newline"><div><div style="word-wrap:break-word;line-break:after-white-space"><br><div><br><blockquote type="cite"><div>On Oct 25, 2017, at 02:34, Xiaodi Wu via swift-dev &lt;<a href="mailto:swift-dev@swift.org" target="_blank">swift-dev@swift.org</a>&gt; wrote:</div><br class="m_4899158335981833298Apple-interchange-newline"><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">Please see earlier replies summarizing core team members&#39; persuasive arguments as to why not multiple protocol hierarchies like this.</div></div></blockquote></div><br><div>Hi Xiaodi,</div><div><br></div><div>The above line is does it help your argument. Even if a person was motivated to search through the entire mailing list archives looking for said arguments, they won’t be able to guess which arguments you found to be persuasive (and who was sufficiently “core” at the time, no less). Can you please provide URLs into the archives? Is that a big ask?</div></div></div></blockquote><br></div><div>If I&#39;m (now) reading this correctly, he put the argument itself at the end of his earlier reply to you:</div></div></div></blockquote><div><br></div></span>Right, to which I replied that I wasn’t proposing the Rust model or your similar “MaybeEquatable” model.</div></div></blockquote><div><br></div><div>The other Dave was proposing such a thing, and that was my reply to him. You&#39;re right that you are proposing something different.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space"><div>I was proposing something different where Float and Int are both Equatable and Substitutable, but neither Equatable nor Substitutable inherit from the other. The former is mathematical and the latter is not (which allows it to deal with NaN payloads, ±0, etc). Generic algorithms care mostly if not completely about mathematics, while generic containers care mostly if not completely about substitutability. They can live alongside each other and get along peacefully/sanely. And if people need to care about both, then at least they have an out.</div></div></blockquote><div><br></div>The issue with this is similar to that in my reply earlier about bitwise comparison of floating-point values. Yes, you can propose some total ordering over floating-point values totally divorced from `==`, but I&#39;m quite certain that people who invoke `sort()` on an array of floating-point values don&#39;t simply want *some* deterministic order, but rather an actual increasing order of numeric values. Likewise, when someone asks if an array contains a floating-point value (say, `10.0 as Decimal`), they generally want to know if *any* representation of that value exists. The point is that _what kind of substitutability_ matters, and the kind that people will expect for floating-point values is the very mathematical substitutability that is supposed to be guaranteed by Equatable, which simply does not accommodate NaN.</div><div class="gmail_quote"><br></div></div></div>