<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">The review of SE-0185 - "Synthesizing Equatable and Hashable conformance". The proposal is available here:<br>
<a href="https://github.com/apple/swift-evolution/blob/master/proposals/0185-synthesize-equatable-hashable.md" rel="noreferrer" target="_blank">https://github.com/apple/<wbr>swift-evolution/blob/master/<wbr>proposals/0185-synthesize-<wbr>equatable-hashable.md</a><br>
<br>
• What is your evaluation of the proposal?<br></blockquote><div><br></div><div>Overall a worthwhile addition. Specific comments:</div><div><ol><li>Opt in a good choice, see 2 below.</li><li>Opt in should be for trivial enums as well, even though this is a breaking change it is clearer.</li><li>The hash function should be more tightly specified, without specifying what it does it is hard to know if it is appropriate to use in a given application. I am not particularly advocating one hash function over another, but rather an explanation of what the user can expect. For example is hash consistent across invocations on the same machine and is it dependent upon the order of stored property declaration. It should also state that the hash function is not consistent across machines, since 32 and 64 bit machines will have a different hash (as an implementation detail the hash function should be required to be different on different machines of the same architecture so that people do not mistakenly assume that for example all 64 bit machines produce the same hash). There has been a number of problems with the Java, Python, etc hash functions because these items were not specified.</li><li>Specifying the exact hash function to be used could be considered, if the hash function is known then dictionary and dictionary like structures can be optimized.</li><li>Synthesis by extensions in the same file should be considered, now that private extends to the file. (As an aside: also Codeable.)</li><li>It is quite possible to have class types automatically synthesize hash and equality by calling super.hashValue and super.equals(Self). The omission seems at odds with treating classes equally to values.</li><li>Same for tuples (should be included).</li><li>Transient is a useful marker in Java and therefore should be considered (would also work well with Codeable).</li></ol><div>Hope the above doesn't read negatively, the proposal as is would be a great addition - the above are suggested improvements rather than show stopping musts.</div></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
• Is the problem being addressed significant enough to warrant a change to Swift?<br></blockquote><div><br></div><div>Yes, I even have a library function that mimics this because I got fed up of writing boiler plate.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
• Does this proposal fit well with the feel and direction of Swift?<br></blockquote><div><br></div><div>Yes, part of rounding off the language.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
• If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?<br></blockquote><div><br></div><div>Yes, see comments above based on experience with other languages</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
• How much effort did you put into your review? A glance, a quick reading, or an in-depth study?<br></blockquote><div><br></div><div>Something I have wanted for a while because I have used this feature in other languages. </div><div><br></div><div> -- Howard.</div></div><br></div></div>