[swift-evolution] [Discussion] Seal `T.Type` into `Type<T>`

Anton Zhilin antonyzhilin at gmail.com
Thu Jul 14 20:33:29 CDT 2016

2016-07-15 3:52 GMT+03:00 Brent Royal-Gordon <brent at architechies.com>:

> > On Jul 14, 2016, at 5:24 PM, Anton Zhilin via swift-evolution <
> swift-evolution at swift.org> 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) {

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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160715/07041431/attachment.html>

More information about the swift-evolution mailing list