> On Jul 20, 2016, at 5:18 PM, Chris Lattner <[email protected]> wrote: > > * What is your evaluation of the proposal?
I think this proposal is a huge mess. I don't understand why the split between `Type` and `Metatype` exists. I think `Mirror` seems half-baked; it ought to be omitted entirely until we can actually design a reflection system. And *I can't even tell if these are actual problems*. It's possible that the design is just fine, but the proposal explains it poorly. At minimum, the proposal should be rewritten and the type names reconsidered. I'm not a person who gets confused by metatypes, but I simply cannot make heads or tails of this proposal. My general sense of this area is that the main problem is the dual meaning of T.Type. T.Type wants to simultaneously be the type of the type instance and the supertype of all subtype type instances. But this breaks down with protocols, because protocol existentials don't conform to themselves. So we end up with `T.Protocol`, which gets confusingly renamed when it crosses generic boundaries. I think the answer here is to split these two roles: 1. `Metatype<T>` is the type of the type instance. `T.self` is of type `Metatype<T>`. (Yes, we can call it `T.metatype` if we want.) Subtype-supertype relationships don't translate directly to metaclasses; `Metatype<Subclass>` is not a subtype of `Metatype<Superclass>`. 2. `T.Subtype` (or `T.SubtypeMetatype`? `T.Conforming`? this needs bikeshedding) is the supertype of all metatypes for `T` and its subtypes. `T.Subtype` is sort of like a protocol, in that there are no concrete instances of it, so it makes no sense to instantiate it. For classes, it only includes required (i.e. inherited) initializers. Happily, I believe—though I may be wrong—that we can mostly resyntax to fix this immediate problem. Adding new capabilities, like extending the metatypes of specific types and adding universal members, can wait (or mostly wait) for another day. (But in general, I would like to see those added directly on `Metatype`, and I would like extending `Metatype<T>` with instance members to be equivalent to extending `T` with static/class members. I'd also like to conform metatypes to protocols, to somehow define `Metatype` in the standard library as a relatively ordinary Swift type, and to have a pony.) > * Is the problem being addressed significant enough to warrant a change > to Swift? Yes. > * Does this proposal fit well with the feel and direction of Swift? I have no idea, because I can't understand the proposal. > * If you have used other languages or libraries with a similar feature, > how do you feel that this proposal compares to those? Most metatype (well, metaclass) systems I've worked with have been in more dynamic, runtime-oriented languages like Objective-C and Ruby. > * How much effort did you put into your review? A glance, a quick > reading, or an in-depth study? I've been following the threads since the beginning. (And I still don't understand the proposal.) I haven't been able to articulate my objections; honestly, I still can't, but I've run out of time to wait and see if I can figure things out. -- Brent Royal-Gordon Architechies _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
