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

[Tony Allevato]

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



>
> -Chris
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170508/60964fe1/attachment.html>