Tuples conform to Equatable, Comparable, and Hashable

[Joe_Groff]

@anandabits

This would also be the case in generic code like I posted above, correct? So it would just see (Int, Int) and the implicit conversion happens outside the generic code from the labeled to the unlabeled tuple types? If that's the case then I agree with your assessment that they're orthogonal issues.

That's right.

[Alejandro (Alejandro Alonso)]

@anandabits

func compareValues<T: Equatable>(_ lhs: T, _rhs: T) { ... }

// Is this allowed?
compareValues((1, 2), (x: 1, 2: y))

// What about this?
compareValues((y: 1, x: 2), (x: 1, 2: y))

// What about this?
compareValues((a: 1, b: 2), (x: 1, 2: y))

(swift) func equals<T: Equatable>(_ lhs: T, _ rhs: T) -> Bool {
          lhs == rhs
        }
(swift) equals((1, 2), (x: 1, y: 2))
// r0 : Bool = true
(swift) equals((y: 1, x: 2), (x: 1, y: 2))
<REPL Input>:1:1: error: type of expression is ambiguous without more context
equals((y: 1, x: 2), (x: 1, y: 2))
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
(swift) equals((a: 1, b: 2), (x: 1, y: 2))
<REPL Input>:1:1: error: conflicting arguments to generic parameter 'T' ('(a: Int, b: Int)' vs. '(x: Int, y: Int)')
equals((a: 1, b: 2), (x: 1, y: 2))
^

[anandabits (Matthew Johnson)]

Perfect, thanks for checking it with your build! I'm really excited to see this moving ahead!

[Alejandro (Alejandro Alonso)]

@GetSwifty

However, my opinion on this is completely dependent on the expected timeline for generalized Tuple protocol conformance. If we're talking sometime in the next year or two, I think it makes sense to wait. Otherwise if it's more of an "eventually it will probably be added", the use case for this pitch seems valuable enough to warrant being added soon.

I'm not quite sure what the timeline is, but the three features that are needed for general purpose tuple conformances to be useful are:

1. Parameterized Extensions
2. Variadic Generics
3. Extend Structural Types

Some of these are certainly much more difficult to implement than others, but all of them must go through designing phase, evolution, etc. Next year or two feels like a good estimate for these, but even if we'll be able to reimplement these conformances by then I still feel that this proposal is useful for users who would like to use this now. From a user standpoint they don't have to worry about migration or anything like that when those become available after they've already started using these conformances in this proposal.

[Alejandro (Alejandro Alonso)]

@Karl

If we added Collection for homogenous tuples, and some kind of syntax shorthand to declare them, wouldn’t it essentially give us fixed-size arrays?

Is it worth going for that now, while we can, or waiting for something like generic value parameters? Bearing in mind that we already import fixed-size arrays from C as tuples, so any FSA design that isn’t a tuple will have large source breakage.

Yes, that would essentially provide us with fixed-size arrays. My personal opinion is to hold off on other convenience conformances until general purpose conformances for tuples arrive. In any case, many may disagree and may start their own thread to propose them.

Spoiler alert: adding new builtin conformances after my initial patch is incredibly easy, but you didn't hear that from me.

[Alejandro (Alejandro Alonso)]

@DevAndArtist

Random question, shouldn‘t tuple also conform to Error when all types conform to Error as some kind of accumulator of errors which itself would be considered as an error?

This could make sense, but I'm not too versed in any sort of error handling in Swift. Feel free to start a new thread discussing this if you think there's something worth hashing over about

[wowbagger (冀卓疌)]

I think it would be very beneficial that tuples conform to Hashable, because then tuples can be used for ID types in Identifiable conformances.

[sveinhal (Svein Halvor Halvorsen)]

What's the status on this? I'm super eager for this moving forward to a proper review stage?

[Alejandro (Alejandro Alonso)]

I had some late feedback on the implementation that I had to address, but I just pushed those changes so hopefully we're good to go!

[anandabits (Matthew Johnson)]

@Alejandro

hopefully we're good to go!

[sveinhal (Svein Halvor Halvorsen)]

Is it possible to push this forward into the review stage? What is missing for that to happen? Is it time and effort from @Alejandro, or is this awaiting on some external dependency? I don't know how one would go about in recruiting a review manager, etc, but I am super eager to get this moving forward, and would like to help in any limited capacity that I can. Maybe @Joe_Groff can assist with the formalities?

[Alejandro (Alejandro Alonso)]

Joe had mentioned in the implementation that he had some work he needed to do (for another issue that they needed to back deploy), but it would allow the back deploy to have uniform behavior from the actual implementation. He just submitted a PR to allow me to update my back deploy implementation, so I'm waiting on that to to be merged. Besides that, my proposal has to wait like everybody else's. I'm trying as hard as I can to get this in!

[sveinhal (Svein Halvor Halvorsen)]

Thanks for the update. I didn’t mean to complain or push you, and I’m sorry if I came out rude.

I guess my question has as much to do with my (limited) understanding of this process, as with this specific proposal. I’m honestly curious about the status, as well as what the next formal step is. How a proposal goes from pitch to review is still not clear to me.

Also I’m super eager about this work! I guess that may come off as being pushy, but I’m honestly just really excited!

[Alejandro (Alejandro Alonso)]

No no, you didn't come off rude at all don't worry!

[sveinhal (Svein Halvor Halvorsen)]

Again, thanks. But have you been assigned a review manager yet, or are you in some kind of queue to get one? Is there a formal requirement that the suggested implementation (which I understand must be given before the review, but not before a pitch) has to be approved from a technical point of view, ie. through a pull request review, before the proposal can be reviewed?

Sorry for asking perhaps stupid questions.

[Alejandro (Alejandro Alonso)]

I’m in the same boat as you, I don’t have much information to provide on the process. This will most likely wait until the 5.4 process because 5.3 has already had its cutoff date.

[Michael_Brown]

Just wanted to check: this includes conformances for Void, right? It's not mentioned explicitly, and in the proposal it says:

all tuples whose elements are themselves Equatable , Comparable , and Hashable .

Which, depending on your interpretation, would exclude Void, since it has no elements.

Can someone confirm that this proposal does in fact include Void?

[Michael_Brown]

I guess the branch name of the PR for the implementation answers my question: Azoy:void-is-equatable

[Joe_Groff]

You're right. "All elements are X" is true when there are no elements, since X is never false in that case.

[Lantua]

@Joe_Groff

You're right. "All elements are X" is true when there are no elements, since X is never false in that case.

What a vacuous statement. (Sorry, I'll see myself out).