[swift-evolution] [Draft][Proposal] Formalized Ordering

Johannes Neubauer neubauer at kingsware.de
Sat Jul 23 02:34:43 CDT 2016

> Am 23.07.2016 um 06:34 schrieb Stephen Canon via swift-evolution <swift-evolution at swift.org>:
>> The point of this design is that `===` means identity and that `.same `
>> also means identity.
>> Since this is new territory I suppose we get to decide what identity
>> means for floating point.  Should +0 and -0 have the same identity or
>> not?  I’ll leave the answer to folks more knowledgable about numerics
>> than I.
> Boy, I take my wife out for a movie and come back to 50 new messages on SE.

I had the same feeling (short nap for the night and 96 new messages to this thread). I really do like the discussion whether NaN != NaN and similar cases are breaking the contract of ==. I think it is. I started some proposals last week [0], where I pointed out, that implementing equivalence relations is error-prone and the std lib is relying on it. We had there these special cases for Floating points, too. I think it is crucial to get `==` right, and then we get `<=` right :).

IMO, the core of the proposals idea is a good one: separating custom implementations from the ones that std lib relies on. Then you could have unchangeable default behavior (in terms of not allowing false-negatives like NaN != NaN) and still have custom implementations. The std lib (and any other library that needs equality and comparable follow the contract) will just continue working.

I didn’t read everything in this thread, but there were proposals to use === instead of isSame, but currently when I write `-0.0 === 0.0` just says that this operator is not implemented for Float (a value type). This makes totally sense, because value types have by definition no identity.

The discussions about is NaN != NaN and will code be portable and the like are reasonable, but Swift should IMO not try to make it easy for programmers of other languages to convert (hey Swift drops i++ and ++i and the like because this is not the focus), but to make it simple „as is“ (so for new programmers and for all who are willing to get oneself into Swift).

So putting all this special semantics for floating point into a special custom implementation would be good with me. It would be great if operators in Swift could contain letters. Then we could have `==` (standard conform) and `==f` or something like this for floating point semantics.

All the best

[0]: https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160718/024599.html

> I need to read the entire thread more carefully, but off the top of my head, I think that `-0 === +0` is False.  If we’re going to have an `isSame` / `isIdentical` / whatever it's called, I would expect it to imply substitutability.  Although -0 == +0, they are not equivalent when substituted:
> - 1/(-0) != 1/0
> - Float(-0).sign != Float(+0).sign
> - etc
> This probably then implies that `<=>` is not `.same` either.  I’ll read the rest of this and respond more completely tomorrow.
> – Steve
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160723/aa8ce6ce/attachment.sig>

More information about the swift-evolution mailing list