[swift-evolution] [Accepted] SE-0185 - Synthesizing Equatable and Hashable conformance

[Xiaodi Wu]

If I understand the question correctly, Robert's asking whether the
possibility that hashes might differ on every execution would causes issues
if, upon deserializing, one stumbles upon a hash collision which did not
occur with the original hashes. And I suppose the answer to that is...yes?


On Wed, Aug 16, 2017 at 6:16 PM, Tony Allevato via swift-evolution <
swift-evolution at swift.org> wrote:

> From what I can tell the hash values of elements in a Set don't come into
> play during encoding/decoding: they're merely serialized as the sequence of
> their elements. https://github.com/apple/swift/blob/
> 2e5817ebe15b8c2fc2459e08c1d462053cbb9a99/stdlib/public/core/
> Codable.swift#L4073-L4097
>
>
> On Wed, Aug 16, 2017 at 4:06 PM Robert Bennett via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>> How do unstable hash values play with Codable? If you encode and save a
>> Set, might you have problems interacting with it in the future? (This is
>> more a Codable question than Hashable, but I figure I might as well ask
>> here)
>>
>> On Aug 16, 2017, at 7:02 PM, Matthew Johnson via swift-evolution <
>> swift-evolution at swift.org> wrote:
>>
>>
>> On Aug 16, 2017, at 5:59 PM, Rudolf Adamkovic via swift-evolution <
>> swift-evolution at swift.org> wrote:
>>
>> That's great. Thanks!
>>
>>
>> Yes, excellent news!  I am *really* looking forward to seeing this
>> proposal make it into an Xcode release!
>>
>>
>> R+
>>
>> On 17 Aug 2017, at 00:46, John McCall <rjmccall at apple.com> wrote:
>>
>> On Aug 16, 2017, at 6:35 PM, Rudolf Adamkovič via swift-evolution <
>> swift-evolution at swift.org> wrote:
>>
>> This is fantastic news! Any chance of this landing in Swift 4.x instead
>> of 5?
>>
>>
>> It it likely to be available in 4.1, but not 4.0.
>>
>> John.
>>
>>
>> R+
>>
>> On 17 Aug 2017, at 00:29, Chris Lattner via swift-evolution <
>> swift-evolution at swift.org> wrote:
>>
>> Proposal Link: https://github.com/apple/swift-evolution/blob/master/
>> proposals/0185-synthesize-equatable-hashable.md
>>
>> The review of SE-0185 “Synthesizing Equatable and Hashable conformance”
>> ran from August 9…15, 2017. Feedback for the feature was glowingly
>> positive, and the proposal is accepted.  The core team discussed the
>> concerns raised in the feedback thread for the proposal.  Here are some
>> rough notes (not intended to be exhaustive), but it is important to
>> recognize that the proposal follows the design of the auto-synthesized
>> Codable proposal, and that many of these same points were discussed when it
>> came up:
>>
>> - The core team feels that adding compiler magic for this case is
>> reasonable because it solves an important user need, and doesn’t preclude
>> the introduction of a more general feature (e.g. like a macro system, or
>> Rust's ‘deriving’ feature) in the future.  When/if that feature is designed
>> and built, the compiler magic can be replaced with standard library magic.
>>
>> - The hash value of a type is not intended to be stable across rebuilds
>> or other changes to the code.  It is ok to change if fields are reordered,
>> the standard library changes the hash function, etc.  Tony pointed this out
>> on-thread, saying:  The stdlib documentation for hashValue states "Hash
>> values are not guaranteed to be equal across different executions of your
>> program. Do not save hash values to use during a future execution.”
>>
>> - The code synthesized is meant to feel like a default implementation
>> that you’re getting for free from a (constrained) extension on the
>> protocol.  This is why conformance to the protocol itself is all that is
>> required, not something like “AutoEquatable”.
>>
>> Many thanks to Tony Allevato for driving forward this proposal.  The
>> patch just needs final code review now - I think we’re all looking forward
>> to this landing, congrats!
>>
>> Chris Lattner
>> Review Manager
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>
> _______________________________________________
> 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/20170816/20e49eb8/attachment.html>