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

[Tony Allevato]

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
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170508/b75ae8a5/attachment.html>