<div style="white-space:pre-wrap">You keep saying that floating point types are "basic internal" types, but part of the purpose of having a FloatingPoint protocol and a separate BinaryFloatingPoint protocol is that you can implement your own decimal type without any compiler magic.<br></div><br><div class="gmail_quote"><div dir="ltr">On Mon, Jul 18, 2016 at 14:28 Johannes Neubauer <<a href="mailto:neubauer@kingsware.de">neubauer@kingsware.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Dear Xiaodi,<br>
<br>
> Am 18.07.2016 um 20:55 schrieb Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" target="_blank">xiaodi.wu@gmail.com</a>>:<br>
><br>
> As mentioned earlier, NaN != NaN, demonstrating that an Equatable instance that does not always equal itself is not "radical." Plainly, your proposal is unworkable.<br>
<br>
1. this is a basic internal type, so it can have a special behavior, since it is a well-designed data type created by the language designers (since there is no need to bootstrap swift from the first bits this is OK).<br>
2. when I made my proposal I didn’t expect that there is such a hard wish for doing things that for sure do **not** comply to the contract of equality (e.g. in order to work with dictionaries and sets). If you allow to implement something like NaN != NaN in custom code, you allow them to implement equality, that is **not reflexive**.<br>
<br>
Swift (AFAIK) has three goals:<br>
<br>
1. simplicity<br>
2. performance<br>
3. safety<br>
<br>
Allowing things like NaN != NaN in custom value types **without** even flagging it with a keyword like `iknowthisisdangerousbutiknowwhatido`, is against goal 3.<br>
<br>
All the best<br>
Johannes<br>
><br>
><br>
> On Mon, Jul 18, 2016 at 13:48 Johannes Neubauer via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br>
><br>
> > Am 18.07.2016 um 14:01 schrieb Johannes Neubauer via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>>:<br>
> ><br>
> ><br>
> >> Am 18.07.2016 um 13:52 schrieb Johannes Neubauer via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>>:<br>
> >><br>
> >>><br>
> >>> Am 18.07.2016 um 13:05 schrieb L. Mihalkovic <<a href="mailto:laurent.mihalkovic@gmail.com" target="_blank">laurent.mihalkovic@gmail.com</a>>:<br>
> >>><br>
> >>> IMHO implementing your proposal would close the door on some of the things you do when building in-memory dbs (T == U -> TRUE for T not related to U), which if swift remains for small apps is not a terrible loss, but may be more of an issue for one day doing big-data with it.<br>
> >><br>
> >> You talk about reference types now, right? I proposed a `default` keyword, which (in a pattern matching fashion) would catch all calls to T == U for which no implementation exists (so this is exactly when T != U). You could of course change for a given type hierarchy the `default` result to `true` if appropriate.<br>
> ><br>
> > This formulation can be misleading: I mean `a == b` where `a: T` and `b: U` and `T != U`. Due to dynamic dispatch even: `a.dynamicType == T && b.dynamicType == U && T != U`.<br>
><br>
> But I think, for such a radical different semantic than the normal interpretation of equality I think I wouldn’t use the `Equatable`-protocol at all, but implement a custom protocol with a custom operator.<br>
> _______________________________________________<br>
> swift-evolution mailing list<br>
> <a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
<br>
</blockquote></div>