> The review of SE-0185 - "Synthesizing Equatable and Hashable conformance".
> The proposal is available here:
> • What is your evaluation of the proposal?
Overall a worthwhile addition. Specific comments:
1. Opt in a good choice, see 2 below.
2. Opt in should be for trivial enums as well, even though this is a
breaking change it is clearer.
3. 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.
4. 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.
5. Synthesis by extensions in the same file should be considered, now
that private extends to the file. (As an aside: also Codeable.)
6. 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.
7. Same for tuples (should be included).
8. Transient is a useful marker in Java and therefore should be
considered (would also work well with Codeable).
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
> • Is the problem being addressed significant enough to warrant a
> change to Swift?
Yes, I even have a library function that mimics this because I got fed up
of writing boiler plate.
• Does this proposal fit well with the feel and direction of Swift?
Yes, part of rounding off the language.
> • If you have used other languages or libraries with a similar
> feature, how do you feel that this proposal compares to those?
Yes, see comments above based on experience with other languages
> • How much effort did you put into your review? A glance, a quick
> reading, or an in-depth study?
Something I have wanted for a while because I have used this feature in
swift-evolution mailing list