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
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
