> On Jul 14, 2016, at 6:33 PM, Anton Zhilin <[email protected]> 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
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
