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

Tue May 9 19:10:05 CDT 2017

I suspected that would be the case with the function, thanks for confirming
Tony.

I agree with Tony that it's not worth slowing down this proposal to get
tuples in, although it would be nice if this proposal applied to all value
types. Thanks for pursuing this proposal, I have no intention of preventing
it from making Swift 4 :)

I'm happy to help with the implementation if that helps get it in, I'd
already started one before I realised you had a branch (I was the one who
message you on twitter).

To clarify though, tuples are a structural type (not nominal), I don't
think that iterating the structure is a hack. I doubt that tuples will get
protocol conformance for a long time.

On Wed, May 10, 2017 at 9:52 AM, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:

> On Tue, May 9, 2017 at 5:53 PM, Tony Allevato via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>> 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. :)
>>
>
> Agree. Instead of adding more hacks to tuples, their being synthesized to
> conform to Equatable (and Hashable) is long overdue and all of this will
> fall out naturally. As it's additive, it'll happen when it happens. There
> will need to be a way to combine hashes together, of course, but a public
> API is certainly its own proposal.
>
>
> 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/ap
>>>>>> ple/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
>>>>>
>>>>>
>>>>
>>>
>> _______________________________________________
>> 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/aa57920c/attachment.html>