<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Jul 18, 2016 at 4:27 PM, Johannes Neubauer <span dir="ltr"><<a href="mailto:neubauer@kingsware.de" target="_blank">neubauer@kingsware.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><div>I think this discussion goes into the wrong direction. Why are we discussing now how these types are implemented? It was just stating the fact, that the swift compiler does not do nothing and swift is a high-level language.</div></div></blockquote><div><br></div><div>Swift is a "high-performance system programming language." It claims to be "memory safe by default" and to offer "high-level constructs"; I see no claim that Swift is safe or high-level in other respects.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><div>I am a fan of bootstrapping (I implemented some bootstrapping processes by myself). If there is a keyword/annotation "iknowwhatido" then these types can be implemented in swift. Still they are implemented by the core team with caution...</div><div><br></div><div>But do you agree with me or not that (1) equality is reflexivity, symmetry, and transitivity, and (2) Swift should support the normal developer in fulfilling this contract and (3) that NaN != NaN is an extremely special case?</div></div></blockquote><div><br></div><div>I do not. While protocols have semantic meaning, it is up to the owner of a conforming type to ensure that the contract is meaningfully fulfilled. I see no principled reason why Swift should have magic specific for `==` or Equatable and not other methods or protocols.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><div>Perhaps it would be a good idea to have the possibility to identify these special cases and allow to model them (e.g. special case: sink value).</div><div><br></div><div>And for the very confident user the default implementation could be deactivated via keyword/annotation.<br><br>Von meinem iPhone gesendet</div><div><div class="h5"><div><br>Am 18.07.2016 um 22:17 schrieb Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" target="_blank">xiaodi.wu@gmail.com</a>>:<br><br></div><blockquote type="cite"><div><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" target="_blank">neubauer@kingsware.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);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>
</div></blockquote></div></div></div></blockquote></div><br></div></div>