Sent from my iPhone
> On Nov 24, 2017, at 4:06 PM, Chris Lattner <[email protected]> wrote: > >> On Nov 24, 2017, at 3:47 PM, Douglas Gregor via swift-evolution >> <[email protected]> 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 >> [email protected] >> https://lists.swift.org/mailman/listinfo/swift-evolution > _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
