On Fri, May 5, 2017 at 12:41 AM, Brent Royal-Gordon <br...@architechies.com> wrote:
> On May 4, 2017, at 3:01 PM, Xiaodi Wu via swift-evolution < > swift-evolution@swift.org> wrote: > > Hmm, I can see the appeal of automatically deriving Equatable and Hashable > conformance, but I'd like that to be opt-in. That is, types should declare > that they are Equatable or Hashable to begin with. It wouldn't have to take > extra syntax, as compiler magic could effectively synthesize default > implementations for == and/or hashValue when all members are themselves > Equatable or Hashable, respectively. > > > Another benefit is that the problem you're currently having with recursion > goes away: from outside the type, you merely need to check if conformance > is declared. > > Explicit with no special syntactic marker is definitely the way to go. It > would work just like Codable is slated to. > Right. I think we've got broad agreement (woohoo!) that this is the sweet spot. > With such a scheme, consideration can be made to accommodating classes too. > > > I would think only final classes could participate in this, since a > subclassable class would need to allow subclasses to override equality, and > you can't override a static `==` operator method. > I work so rarely with classes that I'm embarrassed to have to ask this question: can classes not satisfy Equatable with a `public class func ==`? (My time is not unlimited right now, but I'd be willing to help with either > the proposal or its implementation. This would be a great thing to get into > Swift 4.) >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution