[swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

[Douglas Gregor]

Sent from my iPhone

> On Nov 24, 2017, at 4:06 PM, Chris Lattner <clattner at nondot.org> wrote:
> 
>> On Nov 24, 2017, at 3:47 PM, Douglas Gregor via swift-evolution <swift-evolution at swift.org> wrote:
>> One could imagine adding a “curry” operation to function types:
> 
> Right, having non-nominal types participate in the generics system would be undoubtably awesome! :)
> 
>> Or perhaps making metatypes Hashable so they can be used as keys into a Dictionary:
>> 
>>  extension<T> T.Type: Hashable {
> 
> Ok, so you just happened to pick a simple one:

Yup. Try to make a nominal type to describe labeled tuples. 

> what is the benefit of plumbing knowledge of metatypes through the entire generics system,

That’s not how one would implement this in the compiler. Most of the compiler doesn’t care whether the subject of a protocol conformance is a nominal type or not, and those scattered (but numerous) places that do care should be straightforward to generalize to include structural types. It’s not metatype-specific work.

> rather than define a “Swift.Metatype” type, and defining stuff against it?

It would be a nominal type in name only (pun intended!), with special cases throughout the compiler and ABI—like we have with Optional, except with poorer test coverage. Worse, unlike the generalization I discuss above, where one generalization refactoring makes all structural types work, we’d have to  put in all of the not-really-nominal hacks for each currently-structural type on a case-by-case basis. 

  - Doug

> 
> -Chris
> 
> 
> 
>>    var hashValue: Int {
>>      return ObjectIdentifier(self).hashValue
>>    }
>> 
>>   static func ==(lhs: T.Type, rhs: T.Type) -> Bool { /* standard library magic */ }
>>  }
>> 
>>    - Doug
>> 
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>