De-gyb Tuple.swift.gyb and replace it with variadic generics #85373
Conversation
|
@swift-ci please smoke test |
|
@swift-ci Please benchmark |
|
@swift-ci please smoke test |
|
Ah, this is a fun one -- @slavapestov This seems related to the concessions here: https://forums.swift.org/t/variadic-generics-and-tuple-shuffle-conversions/60694 It looks like we explicitly are not performing the |
| public func !=<each B: Equatable>(lhs: (repeat each B), rhs: (repeat each B)) -> Bool { | ||
| for (lhs, rhs) in repeat (each lhs, each rhs) { | ||
| if lhs == rhs { | ||
| return false | ||
| } | ||
| } | ||
| return true |
There was a problem hiding this comment.
I think it would be nicer if we forwarded to the same member-wise operations, e.g.
guard lhs != rhs else {
return false
}
| /// - lhs: A tuple of `Equatable` elements. | ||
| /// - rhs: Another tuple of elements of the same type as `lhs`. | ||
| @_alwaysEmitIntoClient | ||
| public func ==<each B: Equatable>(lhs: (repeat each B), rhs: (repeat each B)) -> Bool { |
There was a problem hiding this comment.
aside: does the choice of B as the generic parameter name have some particular significance or prior art?
There was a problem hiding this comment.
Ah, no, this was leftover from originally writing it as <A, each B> thinking it might make the algorithm simpler. It didn’t. I’ll rename and make it more verbose!
There was a problem hiding this comment.
the verbosity budget should be flush, what with all the boilerplate removal! 😄
5 participants
This replaces the 2-7ary variadic gyb'd tuple comparison implementations with unified variadic implementations that short-circuit when the first element fails the test.
Unfortunately, the existing gyb'd tuple comparison entry points are all ABI, so we need to leave them in. However, we can just forward them along to the variadic implementation and rename them so they no longer conflict from an overload perspective.