[swift-evolution] Pitch: Automatically deriving Equatable/Hashable for more value types

[Xiaodi Wu]

This is nice. Thanks for taking the time to write it up. I do have some
concerns/questions:

Do the rules you spell out align with those for Codable? I think it is very
important that these are paralleled as closely as possible, and that any
deviations are explicitly called out in the text with reasoning as to why
it must deviate. Knowing when something is synthesized is difficult enough
with one set of rules--two is certainly one too many.

For example, is it permitted to extend a type in the same module in order
to obtain synthesized Codable conformance? How about for a type in a
different module? The same rules should then apply for Equatable and
Hashable synthesis.

Furthermore, does Codable ignore computed properties? If not, then neither
should Equatable and Hashable. There are also some complicated rules with
generics, if I recall, that may force something to be a computed property.
It would be worth exploring if such rules make ignoring computed properties
counterintuitive. For instance, if a user has to redesign the type,
changing a stored property to a computed property just to satisfy certain
rules of the language, and all of a sudden the definition of equality has
silently changed as a consequence, then that could end up being very hard
to debug. If we find that this is a plausible issue, then it might be worth
considering refusing to synthesize Equatable conformance for a type with
any computed properties--obviously limiting, but better limiting than
surprising. To be clear, I'm not suggesting that we do make this
limitation, just that I don't know that the consequences have been
adequately explored for not including computed properties.


On Mon, May 15, 2017 at 17:21 Tony Allevato via swift-evolution <
swift-evolution at swift.org> wrote:

> Yes—the PR of the proposal is here:
> https://github.com/apple/swift-evolution/pull/706
>
> It needs to be updated slightly—I'll remove the references to the
> "multiplicative hash function" recommendation because I ended up using the
> existing _mixInt and xor, which is how the standard library implements its
> Collection hashValues. (The proposal probably really doesn't need to state
> anything about the hash function used, and its entirely an implementation
> detail.)
>
>
> On Mon, May 15, 2017 at 3:18 PM Andrew Bennett <cacoyi at gmail.com> wrote:
>
>> Nice work Tony! Is this proposal up for PR on swift-evolution as well?
>>
>> On Tue, 16 May 2017 at 7:30 am, Tony Allevato <tony.allevato at gmail.com>
>> wrote:
>>
>>> Just to update everyone on the thread—it took a little longer than I'd
>>> hoped to get the kinks out, but I finally have the implementation up as a
>>> PR: https://github.com/apple/swift/pull/9619
>>>
>>> Hopefully there's still enough time to get the proposal reviewed, make
>>> any changes needed, and get this into Swift 4!
>>>
>>>
>>> On Tue, May 9, 2017 at 10:27 PM Brent Royal-Gordon <
>>> brent at architechies.com> wrote:
>>>
>>>> On May 9, 2017, at 3:53 PM, Tony Allevato via swift-evolution <
>>>> swift-evolution at swift.org> wrote:
>>>>
>>>> Likewise, proposing a new public addition to the standard library would
>>>> inspire far more design discussion than I believe we have time for if we
>>>> want this to make Swift 4. :)
>>>>
>>>>
>>>> Agreed. What I would do here is add an `_combineHashes` function (or
>>>> `Hashable` extension method, or whatever is most convenient) to the
>>>> standard library in Swift 4, have your compiler magic feature use it, and
>>>> defer the name-and-interface discussion until Swift 5.
>>>>
>>>> --
>>>> Brent Royal-Gordon
>>>> Architechies
>>>>
>>>> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170515/10ffbc21/attachment.html>