> On Aug 9, 2017, at 4:09 PM, Chris Lattner <clatt...@nondot.org> wrote: > > Hello Swift community, > > The review of SE-0185 - "Synthesizing Equatable and Hashable conformance" > begins now and runs through August 15, 2017. The proposal is available here: > https://github.com/apple/swift-evolution/blob/master/proposals/0185-synthesize-equatable-hashable.md > > > Reviews are an important part of the Swift evolution process. All reviews > should be sent to the swift-evolution mailing list at: > https://lists.swift.org/mailman/listinfo/swift-evolution > > or, if you would like to keep your feedback private, directly to the review > manager. When replying, please try to keep the proposal link at the top of > the message: > > What goes into a review? > > The goal of the review process is to improve the proposal under review > through constructive criticism and, eventually, determine the direction of > Swift. When writing your review, here are some questions you might want to > answer in your review: > > • What is your evaluation of the proposal?
+1, it addresses one of the biggest pain points that cause people to reach for metaprogramming facilities. I have one clarifying point and tweak. The proposal states: > A struct T: Hashable that satisfies the conditions above will receive a > synthesized implementation of var hashValue: Int { get } that uses an > unspecified hash function† to compute the hash value by incorporating the > hash values of the fields as its terms, in definition order. This means that if the hash-combine operation is not commutative, then hashValues are not stable modulo member reordering. Was this scenario explicitly thought through? I don’t think it’s likely to be an issue in practice, but it's an artifact of implicit and ordered member-wise synthesis. It’s not obvious that declaration order is clearly the best order, e.g. declaration order is not necessarily memory-layout order. It might be better to leave the precise order unspecified, so long as it's guaranteed consistent during the execution of a program. > • Is the problem being addressed significant enough to warrant a change > to Swift? Yes > • Does this proposal fit well with the feel and direction of Swift? It's a reasonably scoped chunk of functionality for the biggest pain points, so yes. > • If you have used other languages or libraries with a similar feature, > how do you feel that this proposal compares to those? Haskell and Rust both have “deriving" constructs for generating these kinds of things, and that simplifies a lot of code. > • How much effort did you put into your review? A glance, a quick > reading, or an in-depth study? > Thought about it a bit; read it quickly. > More information about the Swift evolution process is available at: > https://github.com/apple/swift-evolution/blob/master/process.md > > > Thank you, > > Chris Lattner > Review Manager > > > _______________________________________________ > swift-evolution-announce mailing list > swift-evolution-annou...@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution-announce
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution