[swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

Tue Nov 21 17:02:38 CST 2017

> On 21 Nov 2017, at 22:44, Douglas Gregor <dgregor at apple.com> wrote:
> 
> 
> 
>>> On Nov 20, 2017, at 10:31 PM, Chris Lattner <clattner at nondot.org> wrote:
>>> 
>>> 
>>> 
>>> On Nov 20, 2017, at 10:24 PM, David Hart <david at hartbit.com> wrote:
>>> 
>>> 
>>> 
>>> On 21 Nov 2017, at 03:17, Chris Lattner via swift-evolution <swift-evolution at swift.org> wrote:
>>> 
>>>> Yes, I agree, we need variadic generics before we can have tuples conform :-(
>>>> 
>>>> At the end of the day, you want to be able to treat “(U, V, W)” as sugar for Tuple<U,V,W> just like we handle array sugar.  When that is possible, Tuple is just a type like any other in the system (but we need variadics to express it).
>>> 
>>> Eye-opening! Now I understand how important variadic generics are. Somebody should add that example to the Generics Manifesto.
> 
> It’s in there under “extensions of structural types”, here: https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#extensions-of-structural-types
> 
> with this example:
> 
> 	extension<...Elements : Equatable> (Elements...) : Equatable { // extending the tuple type "(Elements...)" to be Equatable
> }
> 
>>> Questions:
>>> 
>>> • Doesn’t this simplification of the type system hoist Variadic Generics back up the list of priorities?
>> 
>> Not above conditional and recursive conformances.
> 
> Right, and we don’t have bandwidth to take on Another Major Generics Feature this year.
> 
>> 
>>> • Would it be desirable to implement them before ABI stability to “remove” tuples from the ABI?
> 
> Tuples are structural types in the ABI (and type system), and should remain that way. So, I disagree with Chris’s suggestion that (U, V, W) will become Tuple<U, V, W>. The most relevant comparison today is Optional, which is technically a nominal type but is treated as a special case basically everywhere in the compiler (and ABI) because it should have been a structural type. I expect optionals to become structural types in the future (the ABI is designed for that) and tuples to remain structural types.

Can somebody explain to me what are 
 nominal and structural types and why Optional should really be a structural type?

>>> • If not, is the current ABI already flexible enough to support them if they are implemented later on?
>> 
>> I am not the expert on this (Doug Gregor is), but I think we can add it later in an ABI additive way.
> 
> Yes, we can add it to the ABI later.
> 
> 	- Doug
> 
>> 
>> -Chris
>> 
>> 
>> 
>> 
>> 
>>>> Once you have that, then you could write conformances in general, as well as conditional conformances that depend on (e.g.) all the element types being equatable.
>>>> 
>>>> 
>>>> We also need that to allow functions conform to protocols, because functions aren’t "T1->T2” objects, the actual parameter list is an inseparable part of the function type, and the parameter list needs variadics.
>>>> 
>>>> -Chris
>>>> 
>>>>> On Nov 20, 2017, at 6:10 PM, Slava Pestov <spestov at apple.com> wrote:
>>>>> 
>>>>> Ignoring synthesized conformances for a second, think about how you would manually implement a conformance of a tuple type to a protocol. You would need some way to statically “iterate” over all the component types of the tuple — in fact this is the same as having variadic generics.
>>>>> 
>>>>> If we had variadic generics, we could implement tuples conforming to protocols, either by refactoring the compiler to allow conforming types to be non-nominal, or by reworking things so that a tuple is a nominal type with a single variadic generic parameter.
>>>>> 
>>>>> Slava
>>>>> 
>>>>>> On Nov 20, 2017, at 9:06 PM, Tony Allevato via swift-evolution <swift-evolution at swift.org> wrote:
>>>>>> 
>>>>>> This is something I've wanted to look at for a while. A few weeks ago I pushed out https://github.com/apple/swift/pull/12598 to extend the existing synthesis to handle structs/enums when a field/payload has a tuple of things that are Equatable/Hashable, and in that PR it was (rightly) observed, as Chris just did, that making tuples conform to protocols would be a more general solution that solves the same problem you want to solve here.
>>>>>> 
>>>>>> I'd love to dig into this more, but last time I experimented with it I got stuck on places where the protocol conformance machinery expects NominalTypeDecls, and I wasn't sure where the right place to hoist that logic up to was (since tuples don't have a corresponding Decl from what I can tell). Any pointers?
>>>>>> 
>>>>>>> On Mon, Nov 20, 2017 at 5:51 PM Chris Lattner via swift-evolution <swift-evolution at swift.org> wrote:
>>>>>>>> On Nov 20, 2017, at 5:48 PM, Kelvin Ma <kelvin13ma at gmail.com> wrote:
>>>>>>>> the end goal here is to use tuples as a compatible currency type, to that end it makes sense for these three protocols to be handled as “compiler magic” and to disallow users from manually defining tuple conformances themselves. i’m not a fan of compiler magic, but Equatable, Hashable, and Comparable are special because they’re the basis for a lot of standard library functionality so i think the benefits of making this a special supported case outweigh the additional language opacity.
>>>>>>> 
>>>>>>> I understand your goal, but that compiler magic can’t exist until there is something to hook it into.  Tuples can’t conform to protocols right now, so there is nothing that can be synthesized.
>>>>>>> 
>>>>>>> -Chris
>>>>>>> 
>>>>>>> 
>>>>>>>> 
>>>>>>>>> On Mon, Nov 20, 2017 at 8:42 PM, Chris Lattner <clattner at nondot.org> wrote:
>>>>>>>>> 
>>>>>>>>>> On Nov 20, 2017, at 5:39 PM, Kelvin Ma via swift-evolution <swift-evolution at swift.org> wrote:
>>>>>>>>>> 
>>>>>>>>>> when SE-185 went through swift evolution, it was agreed that the next logical step is synthesizing these conformances for tuple types, though it was left out of the original proposal to avoid mission creep. I think now is the time to start thinking about this. i’m also tacking on Comparable to the other two protocols because there is precedent in the language from SE-15 that tuple comparison is something that makes sense to write.
>>>>>>>>>> 
>>>>>>>>>> EHC conformance is even more important for tuples than it is for structs because tuples effectively have no workaround whereas in structs, you could just manually implement the conformance. 
>>>>>>>>> 
>>>>>>>>> In my opinion, you’re approaching this from the wrong direction.  The fundamental problem here is that tuples can’t conform to a protocol.  If they could, synthesizing these conformances would be straight-forward.
>>>>>>>>> 
>>>>>>>>> If you’re interested in pushing this forward, the discussion is “how do non-nominal types like tuples and functions conform to protocols”?
>>>>>>>>> 
>>>>>>>>> -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
>>>>> 
>>>> 
>>>> _______________________________________________
>>>> 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/20171122/df8b23ab/attachment.html>