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

[Tony Allevato]

So (borrowing C++-ish notation), a function of type `(Args...) -> Result`
would become sugar for something like `Function<Args..., Result>`? That
certainly makes sense.

How would throw-ness be handled—would we need ThrowingFunction and
Function, with the ability to coerce Function -> ThrowingFunction? (Async
might pose similar issues?)


On Mon, Nov 20, 2017 at 6:17 PM Chris Lattner <clattner at nondot.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).
>
> 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
>>> <https://github.com/apple/swift-evolution/blob/master/proposals/0185-synthesize-equatable-hashable.md>
>>> went through swift evolution, it was agreed that the next logical step
>>> <https://www.mail-archive.com/swift-evolution@swift.org/msg26162.html>
>>> 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
>>> <https://github.com/apple/swift-evolution/blob/master/proposals/0015-tuple-comparison-operators.md>
>>> 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
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171121/cb976150/attachment.html>