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

[Brent Royal-Gordon]

> On Jul 14, 2016, at 6:33 PM, Anton Zhilin <antonyzhilin at gmail.com> wrote:
> 
> And such a feature would look odd on a struct.

But why would it be a struct? Types are obvious candidates to have identities; the type is the same "thing" everywhere it's referred to. Types don't have value semantics; if you perform a mutating operation on a type, that mutation is visible everywhere. Types (at least class types) have subtype relationships; structs can't express those.

I like the `Type<>` syntax, especially if it's something that could at least partially be written in the standard library (how nice would it be if we had `final class Type<Describing>` in the generated headers?), and I really like the idea of extending a metatype to conform to a protocol. But a lot of what's being discussed here, I just don't get. What's the benefit of switching to structs? Of removing type members?

> 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?

Maybe not:

	func recursivelyPrint<T>(type: T.Type, depth: Int) {
		print(type)
		guard depth > 0 else { return }
		recursivelyPrint(type: type.dynamicType, depth: depth - 1)
	}
	recursivelyPrint(type: Int.self, depth: 5)

-- 
Brent Royal-Gordon
Architechies