Yes, and I’ve been arguing for it being explicit by conforming to the Equatable / Hashable protocol. This would then work the same way as protocol extensions. Protocol extension don’t require a special ‘deriving’ keyword, so I don’t believe there needs to be one here. Just conforming to the protocols is enough.
> On 29 May 2016, at 9:42 PM, Matthew Johnson <[email protected]> wrote: > > > > Sent from my iPad > > On May 29, 2016, at 12:28 AM, Patrick Smith <[email protected] > <mailto:[email protected]>> wrote: > >> Yeah I don’t see a problem. It’s the same way that protocol extensions just >> work. Think of this automatic synthesis as a really flexible protocol >> extension: >> >> extension Hashable where Members : Hashable { >> var hashValue : Int { >> return self.allMembers.reduce(^) // Or whatever combiner is best >> } >> } > > Protocol extensions require you to declare conformance before your type > receives their implementation and it must be identical for all do conforming > types. > > You should have to declare conformance to receive Equatable conformance and > synthesis. IMO it makes sense to do that with 'deriving' which makes it > clear that you are requesting synthesized rather than manual conformance. > >> >> >>> On 29 May 2016, at 1:19 PM, Jon Shier via swift-evolution >>> <[email protected] <mailto:[email protected]>> wrote: >>> >>>> The problem with this is that it doesn’t differentiate between synthesized >>>> and manual conformance. You won’t get error messages you otherwise would >>>> when you intend to supply manual conformance. It is also less clear to a >>>> reader of the code that the default, compiler synthesized implementation >>>> is being generated. >>> >>> I don’t think it’s reasonable to force the language down the path where >>> developers don’t have to be familiar with its features in order to use them >>> correctly. If types in Swift were to automatically gain Equatable and >>> Hashable conformances whenever they were used by something that required >>> them, that would be a core language feature, like type inference, that even >>> junior developers in the language would need to know. Yet few (though not >>> none) would insist that all types be manually declared, despite otherwise >>> not knowing when our type inference goes wrong. It’s just a basic feature >>> of the language that anyone using the language should know about, otherwise >>> it can bite them in the ass when weird compiler errors start popping up. >>> Frankly, IMO, this is an obvious case of 80/20 optimization. In the >>> vast majority of cases where my types are trivially equatable, I should >>> just be able to declare them as such and gain the compiler-synthesized ==. >>> In the cases where that’s not possible, the compiler can emit an error. And >>> in the cases where I want a custom == implementation I can provide it. >>> Requiring a new keyword and not making this feature as simple as possible >>> because the rare developer with a custom type who doesn’t want the >>> synthesized == they just said they did by declaring Equatable conformance >>> is an unnecessary defaulting to the rare case. >>> >>> >>> >>> >>> Jon Shier >>> _______________________________________________ >>> swift-evolution mailing list >>> [email protected] <mailto:[email protected]> >>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >>
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
