> 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

Reply via email to