[swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

[Michael Peternell]

I'm not a fan of AutoEquatable or AutoHashable. These protocols suggest that automatic conformance can be defined in the language itself and that derived protocol instances don't have to be implemented as compiler intrinsics. That's just not the case. You cannot define something like

@auto protocol AutoEquatable : Equatable {
   ...
}

because what would you write instead of "..."? Copy Lisp-Macros? Copy Template-Haskell? I don't really need to disagree here, I could just say "good idea, do you want to make a proposal for this?" and then I will never hear again anything from this idea, because no one will be able to write the "detailed design" section of that proposal. (at least, I don't know how to design such a feature; the solution space looks empty to me. there are similar issues with "property behaviors" IMHO, but that's another story.)

Second, there is no point in "prohibiting" any protocols from being "derived". But deriving will only work for protocols for which someone has implemented a deriving algorithm. And that algorithm has to be implemented in the compiler. I think `Comparable`, `CustomStringConvertible` would be good candidates for deriving too. The whole point of all of this is to reduce boilerplate code that is trivial to write, and also error-prone because no one wants to read that boring code carefully (e.g. a custom to-string-function for an enum with 30 cases, that just returns the name of the symbol and that has to be extended each time another case is added: `case Foo1: return "Foo1"; case Bla: return "Bla"; ...`).

Third, what is the difference between "deep equality" (AutoDeepEquatable) and "shallow equality" (AutoShallowEquatable)?

(A tiny bit) sorry for bashing any other opinions... :-/ But, a solution has to 1) work, 2) be practical, 3) be implementable, 4) have a possible detailed design that is not overly baroque, 5) shouldn't have funny edge cases that will disturb users as soon as the feature is used widely.

But since this feature is out-of-scope for Swift 3 anyways, we now have plenty of time resolving all these issues.. I may try to write a proposal later this year, after Swift 3 has been released. Thanks to everyone who participated in the discussion.

-Michael