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

[Andrew Bennett]

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/
>> apple/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/819c9d15/attachment.html>