Synthesizing Equatable, Hashable, and Comparable for tuple types

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. this is especially relevant in
graphics and scientific contexts where tuples are used to represent color
values and points in 2D or 3D space. today you still can’t do things like

let lattice = Dictionary<(Int, Int, Int), AssociatedValue>() .

the commonly suggested “workaround”, which is to “upgrade” the tuple to a
struct is problematic for two reasons:

1. it defeats the purpose of having tuples in the language

2. tuples are a logical currency type for commonly used types like points
and vectors. If every library defined its own custom point/vector types we
would soon (already?) have a nightmare situation where no geometry/graphics
library would be compatible with any other geometry/graphics library, at
least not without a lot of annoying, let alone wasteful swizzling and
manual conversion routines in the main application.

1 Like

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

···

On Nov 20, 2017, at 5:39 PM, Kelvin Ma via swift-evolution <swift-evolution@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.

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.

···

On Mon, Nov 20, 2017 at 8:42 PM, Chris Lattner <clattner@nondot.org> wrote:

On Nov 20, 2017, at 5:39 PM, Kelvin Ma via swift-evolution < > swift-evolution@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

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. this is especially relevant in graphics and scientific contexts where tuples are used to represent color values and points in 2D or 3D space. today you still can’t do things like

let lattice = Dictionary<(Int, Int, Int), AssociatedValue>() .

the commonly suggested “workaround”, which is to “upgrade” the tuple to a struct is problematic for two reasons:

1. it defeats the purpose of having tuples in the language

2. tuples are a logical currency type for commonly used types like points and vectors. If every library defined its own custom point/vector types we would soon (already?) have a nightmare situation where no geometry/graphics library would be compatible with any other geometry/graphics library, at least not without a lot of annoying, let alone wasteful swizzling and manual conversion routines in the main application.

Actually I don't think that tuples should be used for points and vectors at all, because I prefer to differentiate these two concepts which requires nominal types, e.g.

struct Point {
    func distance(to point: Point) -> Vector
    func offsetBy(_ offset: Vector) -> Point
}

Notwithstanding this disagreement I too think that EHC conformance for tuples would be useful.

-Thorsten

···

Am 21.11.2017 um 02:39 schrieb Kelvin Ma via swift-evolution <swift-evolution@swift.org>:

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

It would be a tractable intermediate problem to introduce built-in conformances for tuples (and perhaps metatypes) to Equatable/Hashable/Comparable without breaching the more general topic of allowing these types to have general protocol conformances. I think that would cover the highest-value use cases.

-Joe

···

On Nov 20, 2017, at 5:43 PM, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:

On Nov 20, 2017, at 5:39 PM, Kelvin Ma via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@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.

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 Nov 20, 2017, at 5:48 PM, Kelvin Ma <kelvin13ma@gmail.com> wrote:

On Mon, Nov 20, 2017 at 8:42 PM, Chris Lattner <clattner@nondot.org <mailto:clattner@nondot.org>> wrote:

On Nov 20, 2017, at 5:39 PM, Kelvin Ma via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@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

a good idea on paper, a disastrous one in practice. What happens if every
geometry library declares their own Point type?

···

On Tue, Nov 21, 2017 at 1:15 AM, Thorsten Seitz <tseitz42@icloud.com> wrote:

Am 21.11.2017 um 02:39 schrieb Kelvin Ma via swift-evolution < > swift-evolution@swift.org>:

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. this is especially relevant in
graphics and scientific contexts where tuples are used to represent color
values and points in 2D or 3D space. today you still can’t do things like

let lattice = Dictionary<(Int, Int, Int), AssociatedValue>() .

the commonly suggested “workaround”, which is to “upgrade” the tuple to a
struct is problematic for two reasons:

1. it defeats the purpose of having tuples in the language

2. tuples are a logical currency type for commonly used types like points
and vectors. If every library defined its own custom point/vector types we
would soon (already?) have a nightmare situation where no geometry/graphics
library would be compatible with any other geometry/graphics library, at
least not without a lot of annoying, let alone wasteful swizzling and
manual conversion routines in the main application.

Actually I don't think that tuples should be used for points and vectors
at all, because I prefer to differentiate these two concepts which requires
nominal types, e.g.

struct Point {
    func distance(to point: Point) -> Vector
    func offsetBy(_ offset: Vector) -> Point
}

Notwithstanding this disagreement I too think that EHC conformance for
tuples would be useful.

-Thorsten

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Agree: I think it’s painfully obvious that we want tuples to conform to
Equatable under the appropriate circumstances. Whether this is magic or not
is not strictly settled (though I agree with Kelvin that magic is sensible
here), but right now the issue is that tuples can’t conform to protocols at
all and they very much need to be able to—but how?

···

On Mon, Nov 20, 2017 at 20:51 Chris Lattner via swift-evolution < swift-evolution@swift.org> wrote:

On Nov 20, 2017, at 5:48 PM, Kelvin Ma <kelvin13ma@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@nondot.org> > wrote:

On Nov 20, 2017, at 5:39 PM, Kelvin Ma via swift-evolution < >> swift-evolution@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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@swift.org> wrote:

On Nov 20, 2017, at 5:48 PM, Kelvin Ma <kelvin13ma@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@nondot.org> > wrote:

On Nov 20, 2017, at 5:39 PM, Kelvin Ma via swift-evolution < >> swift-evolution@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

we’d end up with the same situation we have now where everyone declares their own Result type.

Dave

···

On Nov 20, 2017, at 11:32 PM, Kelvin Ma via swift-evolution <swift-evolution@swift.org> wrote:

a good idea on paper, a disastrous one in practice. What happens if every geometry library declares their own Point type?

a good idea on paper, a disastrous one in practice. What happens if every geometry library declares their own Point type?

Well, if I really had the need to use several geometry libraries at once I would have to convert, of course. But I prefer that to the loss of type safety where I could confuse points, vectors and probably more, like colors or whatever else ends up as a tuple...

-Thorsten

···

Am 21.11.2017 um 07:32 schrieb Kelvin Ma <kelvin13ma@gmail.com>:

On Tue, Nov 21, 2017 at 1:15 AM, Thorsten Seitz <tseitz42@icloud.com> wrote:

Am 21.11.2017 um 02:39 schrieb Kelvin Ma via swift-evolution <swift-evolution@swift.org>:

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. this is especially relevant in graphics and scientific contexts where tuples are used to represent color values and points in 2D or 3D space. today you still can’t do things like

let lattice = Dictionary<(Int, Int, Int), AssociatedValue>() .

the commonly suggested “workaround”, which is to “upgrade” the tuple to a struct is problematic for two reasons:

1. it defeats the purpose of having tuples in the language

2. tuples are a logical currency type for commonly used types like points and vectors. If every library defined its own custom point/vector types we would soon (already?) have a nightmare situation where no geometry/graphics library would be compatible with any other geometry/graphics library, at least not without a lot of annoying, let alone wasteful swizzling and manual conversion routines in the main application.

Actually I don't think that tuples should be used for points and vectors at all, because I prefer to differentiate these two concepts which requires nominal types, e.g.

struct Point {
    func distance(to point: Point) -> Vector
    func offsetBy(_ offset: Vector) -> Point
}

Notwithstanding this disagreement I too think that EHC conformance for tuples would be useful.

-Thorsten

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

a good idea on paper, a disastrous one in practice. What happens if every geometry library declares their own Point type?

That would be ugly („disastrous“ imho is a little bit to strong — C++ had/has similar issues, and other languages as well)
But if there would be a simple Point struct in a library that is popular (could be achieved by shipping it alongside the stdlib), this problem would be solved (there has been a pitch lately, but I guess it faded away silently).

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.

It would be a tractable intermediate problem to introduce built-in conformances for tuples (and perhaps metatypes) to Equatable/Hashable/Comparable without breaching the more general topic of allowing these types to have general protocol conformances. I think that would cover the highest-value use cases.

So, shouldn't we do this first step ASAP and then design a good common solution to allow tuples/metatypes/funcs to confirm to custom protocols in some next version of Swift?
I really believe this is the good practical decision and will be supported by community if such proposal will be on the table.
Is there any drawback in such step?

Vladimir.

···

On 27.11.2017 20:28, Joe Groff via swift-evolution wrote:

On Nov 20, 2017, at 5:43 PM, Chris Lattner via swift-evolution <swift-evolution@swift.org >> <mailto:swift-evolution@swift.org>> wrote:

On Nov 20, 2017, at 5:39 PM, Kelvin Ma via swift-evolution <swift-evolution@swift.org >>> <mailto:swift-evolution@swift.org>> wrote:

-Joe

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Yes, I agree, we need variadic generics before we can have tuples conform :frowning:

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@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@swift.org <mailto:swift-evolution@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@swift.org <mailto:swift-evolution@swift.org>> wrote:
On Nov 20, 2017, at 5:48 PM, Kelvin Ma <kelvin13ma@gmail.com <mailto:kelvin13ma@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@nondot.org <mailto:clattner@nondot.org>> wrote:

On Nov 20, 2017, at 5:39 PM, Kelvin Ma via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@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@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

1 Like

can we go the route of SE-15 and just synthesize up to some sensible n = 7 or whatever. i feel like this list has a habit of going “but it would be a lot better to add X if we just wait until Y is a thing first” ignoring that Y will probably not be a thing for the forseeable future and we really need X right now

Sure, you can generate implementations of == or hashing functions, but that won’t let you use them as the key to a dictionary. For that, you need actual conformance.

-Chris

···

On Nov 20, 2017, at 6:30 PM, Kelvin Ma via swift-evolution <swift-evolution@swift.org> wrote:

On Mon, Nov 20, 2017 at 9:10 PM, Slava Pestov via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> 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@swift.org <mailto:swift-evolution@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@swift.org <mailto:swift-evolution@swift.org>> wrote:
On Nov 20, 2017, at 5:48 PM, Kelvin Ma <kelvin13ma@gmail.com <mailto:kelvin13ma@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@nondot.org <mailto:clattner@nondot.org>> wrote:

On Nov 20, 2017, at 5:39 PM, Kelvin Ma via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@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@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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@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@swift.org <mailto:swift-evolution@swift.org>> wrote:
On Nov 20, 2017, at 5:48 PM, Kelvin Ma <kelvin13ma@gmail.com <mailto:kelvin13ma@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@nondot.org <mailto:clattner@nondot.org>> wrote:

On Nov 20, 2017, at 5:39 PM, Kelvin Ma via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@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@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

2 Likes

can we go the route of SE-15 and just synthesize up to some sensible n = 7
or whatever. i feel like this list has a habit of going “but it would be a
lot better to add X if we just wait until Y is a thing first” ignoring that
Y will probably not be a thing for the forseeable future and we really need
X right now

···

On Mon, Nov 20, 2017 at 9:10 PM, Slava Pestov via swift-evolution < swift-evolution@swift.org> 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@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@swift.org> wrote:

On Nov 20, 2017, at 5:48 PM, Kelvin Ma <kelvin13ma@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@nondot.org> >> wrote:

On Nov 20, 2017, at 5:39 PM, Kelvin Ma via swift-evolution < >>> swift-evolution@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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@nondot.org> wrote:

Yes, I agree, we need variadic generics before we can have tuples conform
:frowning:

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@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@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@swift.org> wrote:

On Nov 20, 2017, at 5:48 PM, Kelvin Ma <kelvin13ma@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@nondot.org> >> wrote:

On Nov 20, 2017, at 5:39 PM, Kelvin Ma via swift-evolution < >>> swift-evolution@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Yes, I agree, we need variadic generics before we can have tuples conform :frowning:

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. Questions:

• Doesn’t this simplification of the type system hoist Variadic Generics back up the list of priorities?
• Would it be desirable to implement them before ABI stability to “remove” tuples from the ABI?
• If not, is the current ABI already flexible enough to support them if they are implemented later on?

···

On 21 Nov 2017, at 03:17, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:

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@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@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@swift.org> wrote:

On Nov 20, 2017, at 5:48 PM, Kelvin Ma <kelvin13ma@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@nondot.org> wrote:

On Nov 20, 2017, at 5:39 PM, Kelvin Ma via swift-evolution <swift-evolution@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Yes, I agree, we need variadic generics before we can have tuples conform :frowning:

Well, we don’t *have* to have variadic generics to allow structural types to conform… it just composes really, really elegantly. One could certainly allow extensions of tuple types with fixed arity, which would then provide conditional conformances:

extension<T: Equatable, U: Equatable> (T, U): Equatable {
  // ...
}

extension<T: Equatable, U: Equatable, V: Equatable> (T, U, V): Equatable {
  // ...
}

Yes, the variadic suggestion is more general and more elegant, but these are orthogonal features.

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.

As noted in my previous reply, we don’t need Tuple<U, V, W> to make this work.

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.

Variadics aren’t enough to fully generalize parameter lists, though, because they don’t capture calling conventions. It’s actually a bit of an issue for Swift, because something variadic like:

  extension<Result, …Params…> (Params…) -> Result { }

Isn’t going to work with “inout”, or with shared/owned (whatever is not the default).

  - Doug

···

On Nov 20, 2017, at 6:17 PM, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:

-Chris

On Nov 20, 2017, at 6:10 PM, Slava Pestov <spestov@apple.com <mailto:spestov@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@swift.org <mailto:swift-evolution@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@swift.org <mailto:swift-evolution@swift.org>> wrote:
On Nov 20, 2017, at 5:48 PM, Kelvin Ma <kelvin13ma@gmail.com <mailto:kelvin13ma@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@nondot.org <mailto:clattner@nondot.org>> wrote:

On Nov 20, 2017, at 5:39 PM, Kelvin Ma via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@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@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution