said as much privately (just not that colorfully though) to author, trying to hint at a number of problems that limited its usefulness.
Regards LM (From mobile) On Jul 21, 2016, at 11:30 AM, Brent Royal-Gordon via swift-evolution <[email protected]> wrote: >> 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 _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
