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

Tue May 9 17:53:58 CDT 2017

While I agree that it would be nice to handle tuples in those contexts, it
also adds a fair amount of complexity to the implementation of the
synthesis. I imagine that time would be better spent just making tuples
conform to Equatable/Hashable properly instead of hacking it, because then
the support falls out naturally; I'd strongly prefer not to squeeze in more
special cases to the proposal that could be done additively later.

Likewise, proposing a new public addition to the standard library would
inspire far more design discussion than I believe we have time for if we
want this to make Swift 4. :)

On Tue, May 9, 2017 at 3:48 PM Andrew Bennett <cacoyi at gmail.com> wrote:

> 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/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/20170509/0cee0eb5/attachment.html>