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

[Andrew Bennett]

Also, when implementing this proposal it's going to be necessary to combine
multiple hashes together. It would be awesome if this was done in a
reusable way. If it doesn't slow the proposal down it would be awesome if
it also introduced a stdlib function:

public func combine_hashes(_ elements: [Int]) -> Int {

    ...

}

Thanks!
Andrew

On Wed, May 10, 2017 at 8:45 AM, Andrew Bennett <cacoyi at gmail.com> wrote:

> You state that you will not synthesise conformance for tuples, I agree
> with this, but if a struct or enum holds a tuple it would be nice if it
> could be hashed if its members are all hashable.
>
> struct A {
>
>   var a: Int, b: Int, c: Int
>
> }
>
>
> struct B {
>
>   var tuple: (a: Int, b: Int, c: Int)
>
> }
>
> I'd consider these two to be equivalent as far as this proposal is
> concerned, it would be nice if the proposal made that explicit.
>
>
> On Tue, May 9, 2017 at 7:17 AM, Tony Allevato via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>>
>>
>> On Mon, May 8, 2017 at 2:11 PM Matthew Johnson <matthew at anandabits.com>
>> wrote:
>>
>>> On May 8, 2017, at 4:02 PM, Tony Allevato <tony.allevato at gmail.com>
>>> wrote:
>>>
>>> On Sat, May 6, 2017 at 4:17 PM Chris Lattner <clattner at nondot.org>
>>> wrote:
>>>
>>>> On May 5, 2017, at 11:33 AM, Tony Allevato via swift-evolution <
>>>> swift-evolution at swift.org> wrote:
>>>>
>>>>
>>>>
>>>>>
>>>>> Can the opt-in conformance be declared in an extension?  If so, can
>>>>> the extension be in a different module than the original declaration?  If
>>>>> so, do you intend any restrictions, such as requiring all members of the
>>>>> type declared in a different module to be public?  My initial thought is
>>>>> that this should be possible as long as all members are visible.
>>>>>
>>>>
>>>> Declaring the conformance in an extension in the same module should
>>>> definitely be allowed;
>>>>
>>>>
>>>> Please follow the precedent of the Codable proposal as closely as
>>>> possible.  If you’d like this to be successful for Swift 4, you should look
>>>> to scope it as narrowly as possible.  Because it is additive (with opt-in),
>>>> it can always be extended in the future.
>>>>
>>>> I believe this would currently be the only way to support conditional
>>>> conformances (such as the `Optional: Hashable where Wrapped: Hashable`
>>>> example in the updated draft), without requiring deeper syntactic changes.
>>>>
>>>>
>>>> This proposal doesn’t need to cover all cases, since it is just
>>>> sugaring a (very common) situation.  Conditional conformances to Hashable
>>>> could be written manually.
>>>>
>>>> I'm less sure about conformances being added in other modules,
>>>>
>>>>
>>>> It is a bad idea, it would break resilience of the extended type.
>>>>
>>>> But after writing this all out, I'm inclined to agree that I'd rather
>>>> see structs/enums make it into Swift 4 even if it meant pushing classes to
>>>> Swift 4+x.
>>>>
>>>>
>>>> Agreed, keep it narrow to start with.
>>>>
>>>> Also, I don’t know how the rest of the core team feels about this, but
>>>> I suspect that they will be reticent to take an additive proposal at this
>>>> late point in the schedule, unless someone is willing to step up to provide
>>>> an implementation.
>>>>
>>>
>>> That someone is me :)  I have a branch where it's working for enums
>>> (modulo some weirdness I need to fix after rebasing a two-month-old state),
>>> and adapting that logic to structs should hopefully be straightforward
>>> after that. Going with the more narrowly-scoped proposal and making
>>> conformances explicit simplifies the implementation a great deal as well (I
>>> was previously blocked with recursive types when it was implicit).
>>>
>>> Thanks for the feedback—after consideration, I've pulled classes out of
>>> the proposal completely (even non-final) and mentioned the other
>>> limitations so we'd have a record of what was discussed in this thread.
>>>
>>> I've created a PR for the proposal text, in the event that the core team
>>> is interested in moving this forward: https://github.com/ap
>>> ple/swift-evolution/pull/706
>>>
>>>
>>> Thanks for continuing to push this forward Tony!  The current proposal
>>> looks like the right approach for getting this into Swift 4.
>>>
>>> I only have one question which I will present with an example:
>>>
>>> protocol Foo: Equatable {}
>>> protocol Bar: Hashable {}
>>>
>>> struct FooType: Foo {}
>>> struct BarType: Bar {}
>>>
>>> Do FooType and BarType receive synthesis?
>>>
>>
>> Great question! Yes they should. It's "explicit" transitively since the
>> answer to "does FooType/BarType conform to Equatable/Hashable?" is still
>> "yes". (And I've confirmed that my prototype handles this case.)
>>
>> This is especially helpful since Hashable extends Equatable, so a user
>> only needs to list conformance to the former to get correctly synthesized
>> implementations of both, which helps to guarantee that they're implemented
>> consistently with respect to each other.
>>
>>
>>
>>>
>>>
>>>
>>>
>>>>
>>>> -Chris
>>>>
>>>>
>>>>
>>>
>> _______________________________________________
>> 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/20170510/72b6b6b8/attachment.html>