2016-07-15 3:52 GMT+03:00 Brent Royal-Gordon <[email protected]>:
> > On Jul 14, 2016, at 5:24 PM, Anton Zhilin via swift-evolution < > [email protected]> wrote: > > > > Ok, I forgot about it. Type<T> should have all features of T.Type, > except that Type<T> will not contain static methods of T. > > Why? It seems to me like the most natural way to design this by far is to > have `Type<T>` be the type returned by `type(of:)`, which means it would > have all static and class members on it. An example where such behavior is required: protocol HasStatic { static func staticMethod() } func callStatic(_ type: HasStatic.Type) { type.staticMethod() } I finally understand the reasons for keeping metatypes T.Type, "sealed" inside Type<T>. And such a feature would look odd on a struct. It also seems like `Type<T>`'s type would absolutely have to be > `Type<Type<T>>`, and some form of infinite regress is absolutely necessary > (though in practice it could probably be simulated by having the first > metatype with no static members act as its own type, or with some other > form of lazy instantiation). I don't see any problems with Type<Type<T>>. There is finite number of types that are used in the program, and compiler can collect and store information about them all statically. Am I right?
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
