[swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types
svabox at gmail.com
Tue Nov 28 12:52:28 CST 2017
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 at swift.org
>> <mailto:swift-evolution at swift.org>> wrote:
>>> On Nov 20, 2017, at 5:39 PM, Kelvin Ma via swift-evolution <swift-evolution at swift.org
>>> <mailto: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://firstname.lastname@example.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
Is there any drawback in such step?
> swift-evolution mailing list
> swift-evolution at swift.org
More information about the swift-evolution