[swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types
tony.allevato at gmail.com
Mon Nov 20 20:31:50 CST 2017
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
> 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.
> 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
> 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.
>> On Mon, Nov 20, 2017 at 8:42 PM, Chris Lattner <clattner at nondot.org>
>>> 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”?
>> swift-evolution mailing list
>> swift-evolution at swift.org
> swift-evolution mailing list
> swift-evolution at swift.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution