<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jul 18, 2016 at 5:15 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div><br><br>Von meinem iPhone gesendet</div><span class=""><div><br>Am 18.07.2016 um 23:46 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 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></div></div></blockquote><div><br></div></span><div>"Easy to learn", and "safe" are attributes that were part of Swifts profile from the very beginning: 2-phase initialization, optionals, type-safety, no wild-cards for generics, special associated type Self (used for equals and compare for instance)...</div><span class=""><div><br></div><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><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>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></div></blockquote><div><br></div></span>There are a lot of papers and books around in (scientific) literature about generics, inheritance (e.g. fragile base class problem), the billion dollar mistake `null`, off-by-one, just to mention a few, and Swift addresses a lot of these problems already (some better and some not as good). I would like to propose an option how we can narrow a problem space and you talk about magic and constraining freedom.</div></blockquote><div><br></div><div>I use "magic" to mean functionality built into the compiler that cannot be expressed in Swift itself. Without behaviors, attributes require magic, and because there is no syntax in Swift that can make every function named `==` call a function named `===`, that too will require magic. I am not sure why you are putting words in my mouth; I have never used the word "freedom."</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto">If you like freedom perhaps a dynamically typed language like Python is the weapon to choose for you (no offense). But type systems are for safety and static type systems constrain the developer in order to reduce the possibility of bugs. There is always a tension between safety and expressiveness.<div><br></div><div>I really did a lot of research in these topics and just would like to share my knowledge and experience with the community, I do not want to steal anyone any feature or something like that. I would really appreciate if we could discuss whether an additional safety net for equality, that can be deactivated in rare occasion when the developer insists (like forced unwrapping for optionals) is something that the Swift community (and the core team) would like to have or not. If not, I will not fight for it, because I think we all do not have the time to discuss this to the end of all time :).</div><div><br></div><div>All the best</div><div><span class="HOEnZb"><font color="#888888">Johannes</font></span><span class=""><br><div><br></div><div><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><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></div></div></blockquote></div></div></div>
</blockquote></div></span></div></div></blockquote></div><br></div></div>