<div dir="ltr">On Sat, Apr 22, 2017 at 7:02 PM, Matthew Johnson <span dir="ltr"><<a href="mailto:matthew@anandabits.com" target="_blank">matthew@anandabits.com</a>></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 dir="auto"><div><br><br>Sent from my iPad</div><div><div class="h5"><div><br>On Apr 22, 2017, at 4:53 PM, Xiaodi Wu via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr">On Sat, Apr 22, 2017 at 4:14 PM, Dave Abrahams <span dir="ltr"><<a href="mailto:dabrahams@apple.com" target="_blank">dabrahams@apple.com</a>></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 class="m_-8433840705966135716HOEnZb"><div class="m_-8433840705966135716h5"><br>
on Tue Apr 18 2017, Xiaodi Wu <<a href="http://xiaodi.wu-AT-gmail.com" rel="noreferrer" target="_blank">xiaodi.wu-AT-gmail.com</a>> wrote:<br>
<br>
> On Tue, Apr 18, 2017 at 10:40 AM, Ben Cohen via swift-evolution <<br>
> <a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br>
><br>
>><br>
>> On Apr 17, 2017, at 9:40 PM, Chris Lattner via swift-evolution <<br>
>> <a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br>
>><br>
>><br>
>> On Apr 17, 2017, at 9:07 AM, Joe Groff via swift-evolution <<br>
>> <a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br>
>><br>
>><br>
>> On Apr 15, 2017, at 9:49 PM, Xiaodi Wu via swift-evolution <<br>
>> <a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br>
>><br>
>> For example, I expect `XCTAssertEqual<T : FloatingPoint>(_:_:)` to be<br>
>> vended as part of XCTest, in order to make sure that `XCTAssertEqual(resultOfComput<wbr>ation,<br>
>> Double.nan)` always fails.<br>
>><br>
>><br>
>> Unit tests strike me as an example of where you really *don't* want level<br>
>> 1 comparison semantics. If I'm testing the output of an FP operation, I<br>
>> want to be able to test that it produces nan when I expect it to, or that<br>
>> it produces the right zero.<br>
>><br>
>><br>
>> I find it very concerning that == will have different results based on<br>
>> concrete vs generic type parameters. This can only lead to significant<br>
>> confusion down the road. I’m highly concerned about situations where<br>
>> taking a concrete algorithm and generalizing it (with generics) will change<br>
>> its behavior.<br>
>><br>
>><br>
>> It is already the case that you can start with a concrete algorithm,<br>
>> generalize it, and get confusing results – just with a different starting<br>
>> point. If you start with a concrete algorithm on Int, then generalize it to<br>
>> all Equatable types, then your algorithm will have unexpected behavior for<br>
>> floats, because these standard library types fail to follow the rules<br>
>> explicitly laid out for conforming to Equatable.<br>
>><br>
>> This is bad. Developers need to be able to rely on those rules. The<br>
>> standard library certainly does:<br>
>><br>
>> let a: [Double] = [(0/0)]<br>
>> var b = a<br>
>><br>
>> // true, because fast path buffer pointer comparison:<br>
>> a == b<br>
>><br>
>> b.reserveCapacity(10) // force a reallocation<br>
>><br>
>> // now false, because memberwise comparison and nan != nan,<br>
>> // violating the reflexivity requirement of Equatable:<br>
>> a == b<br>
>><br>
>><br>
>> Maybe we could go through and special-case all the places in the standard<br>
>> library that rely on this, accounting for the floating point behavior<br>
>> (possibly reducing performance as a result). But we shouldn't expect users<br>
>> to.<br>
>><br>
><br>
> I was not thinking about the issue illustrated above, but this is<br>
> definitely problematic to me.<br>
><br>
> To be clear, this proposal promises that `[0 / 0 as Double]` will be made<br>
> to compare unequal with itself, yes?<br>
<br>
</div></div>Nope.<br>
<br>
As you know, equality of arrays is implemented generically and based on<br>
the equatable conformance of their elements. Therefore, two arrays of<br>
equatable elements are equal iff the conforming implementation of<br>
Equatable's == is true for all elements.<br>
<span><br>
> It is very clear that here we are working with a concrete FP type and<br>
> not in a generic context, and thus all IEEE FP behavior should apply.<br>
<br>
</span>I suppose that's one interpretation, but it's not the right one.<br>
<br>
If this were C++, it would be different, because of the way template<br>
instantiation works: in a generic context like the == of Array, the<br>
compiler would look up the syntactically-available == for the elements<br>
and use that. But Swift is not like that; static lookup is done at the<br>
point where Array's == is compiled, and it only finds the == that's<br>
supplied by the Element's Equatable conformance.<br>
<br>
This may sound like an argument based on implementation details of the<br>
language, and to some extent it is. But that is also the fundamental<br>
nature of the Swift language (and one for which we get many benefits),<br>
and it is hopeless to paper over it. For example, I can claim that all<br>
doubles are equal to one another:<br>
<br>
9> func == (lhs: Double, rhs: Double) -> Bool { return true }<br>
10> 4.0 == 1.0<br>
$R2: Bool = true<br>
11> [4.0] == [1.0] // so the arrays should be equal too!<br>
$R3: Bool = false<br>
<br>
Another way to look at this is that Array is not a numeric vector, and<br>
won't be one no matter what you do ([1.0] + [2.0] => [1.0, 2.0]). So it<br>
would be wrong for you to expect it to reflect the numeric properties of<br>
its elements.<br></blockquote><div><br></div><div>I understand that's how the generic Array<T> would work, but the proposal as written promises FP-aware versions of these functions. That is to say, I would expect the standard library to supply an alternative implementation of equality for Array<T where T : FloatingPoint>.</div></div></div></div></div></blockquote><div><br></div></div></div>Are you suggesting it implies that Array's Equatable conformance is implemented differently when T: FloatingPoint? Is it even possible to provide such an implementation given the current restriction that bans overlapping conformance? (If there is a technique for implementing something like this in Swift 4 I would love to learn it)</div></blockquote><div><br></div><div>I don't believe it's possible, but there is compiler magic being proposed to make this protocol stick together, so we are not bound by the limits of Swift 4-expressible designs.</div><div><br></div></div></div></div>