[swift-evolution] Pitch: Automatically deriving Equatable/Hashable for more value types
tony.allevato at gmail.com
Mon May 8 16:02:04 CDT 2017
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:
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution