<div dir="ltr">Forbidding custom `==` for value types would break equality for all Swift collection types, since they use reference types behind the scenes for storing memory and copy on write semantics. Furthermore, why should properties pointing to reference types always use `===`? What if the reference type conforms to `Equatable`?<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jul 14, 2016 at 1:36 PM, Johannes Neubauer via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Dear Evolutionaries,<br>
<br>
First off, I like Swift!<br>
<br>
I have some proposals for swift 3ff. (since the `++` operator is discouraged ;) ):<br>
<br>
1. Custom implementation of equals operator `==` for value types should be forbidden. Rationale: Why has it been added in the first place? For omitting some values from the equals test? A user may introduce side-effects in that very method, i.e., check some global variable. It should to the most be allowed to mark/annotate some properties with `transient` or some better name, in order to prevent it being part of the equals test. But I would discourage the ability to omit some of the values from the equals test, since it does not make sense for value types, does it? If a value instance is equal to another, but the value may differ... this is odd semantics. Properties pointing at reference types should be tested with `===`. The `hashValue` for `Hashable` value types, should be auto-computed, too. Since a value type is "kind of" immutable (will be copied if it is changed), the hash value can be cached.<br>
2. `dispatch` keyword on functions/parameters especially for operators. Which leads to dynamic dispatch of one or more parameters (as defined via the keyword). Rationale: Swift is a multi-paradigm language. It is neither as hard with immutability as Haskell is, but not as open as Python or whatever. I see Swift as a golden middle course. This is why in Swift value and reference types coexist, isn't it? So, although the focus seems to lie on value types and static dispatch, the dynamic world still is your frient, right? Adding dynamic/multi dispatch on-demand would be great. Now I have to implement it by defining an operator on a super type and implement an instance method, which the operator can delegate to. Last but not least, in the instance method I have to do the dispatch of the second parameter by hand. This feature could be used wonderfully together with value types using your great Existential Containers, too.<br>
3. As a follow-up to *2.*: `default`-case for methods/operators like equals (`==`) to allow safe polymorphic calls for mixed types (or even complete pattern matching for method overloading, like many functional languages do it for having functions with different entry points for different values). Rationale: If you could add a `default`-case (e.g. as an additional statement to the `return` or beneath the definition of the return type in the method head) which returns `false`, then you could safely implement all `T == T` checks and all `T == U` checks will just return false. This does not make sense for all methods, but I can imagine of more than just equals ;) . This way swift could soften the requirement of PATs (Protocol with Associated Types) with the associated type `Self`. This would be a very first step to existentials... leading to the next and last proposal for today<br>
4. Add poor-mans existentials which allow to access non-PAT methods as well as methods with a `default`-case (see *3.*). Rationale: I read the [generics manifesto][0] and really liked the part [existentials][1]. In a first step I wouldn't do complicated things like chaining existentials, but do something similar like in structs with `mutating` functions: You just cannot call them on `let` variables (compiler error). The same could be done for methods using the associated type in their signature (because of the co-/contravariance problem) unless the associated type is `Self` and the function has a `default`-clause. By the way I think, that not implementing pseudo-existentials (like Java and Kotlin do with their wildcards or variance declarations `in`/`out` respectively) and I hope that the existentials will come to swift in the future... I was a little bit afraid that the "Existentials" section is beneath "Unlikely" and "Potential Removals", but since these headings are on the same level, this does not mean that implementing existentials in the future are unlikely, does it? I have some ideas how they could fit into the language very well, if you like to hear them...?<br>
<br>
I would really appreciate discussing these 4 proposals :) .<br>
<br>
All the best<br>
Johannes<br>
<br>
[0]: <a href="https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md" rel="noreferrer" target="_blank">https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md</a><br>
[1]: <a href="https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#existentials" rel="noreferrer" target="_blank">https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#existentials</a><br>
<br>
--<br>
Dr. Johannes Neubauer<br>
E-Mail: <a href="mailto:neubauer@kingsware.de">neubauer@kingsware.de</a><br>
WWW : <a href="http://www.kingsware.de" rel="noreferrer" target="_blank">http://www.kingsware.de</a><br>
<br>
<br>_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">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><br></div>