Okay I’m convinced on that one, but do we really want to give up being able to
construct an instance from an metatype instance? (Personally I’d keep it as an
optional feature.)
There are more than 7000 search results inside swift repository for .Type.
I looked up a few of them and I found an interesting example:
a = SomeClass.self
expectTrue(a as? Any.Type == SomeClass.self)
expectTrue(a as? AnyClass == SomeClass.self)
expectTrue(a as? SomeClass.Type == SomeClass.self)
After this proposal we had this:
a: Type<SomeClass> = SomeClass
// How can we cast from `Type<SomeClass>` to `Type<Any>`?
// Comparing two Type<T> is done with `hashValue` at least in my
// implementation.
expectTrue(a as? Type<Any> == SomeClass) // `SomeClass` equals
`Type<SomeClass>()`
// How can we cast `Type<SomeClass>` to `AnyClass`?
expectTrue(a as? AnyClass == SomeClass)
// this is fine
expectTrue(a as? Type<SomeClass> == SomeClass)
Dynamic casts do not work with other instances of metatypes (I feel like there
was a proposal for this, but I can’t find it). If we had this, we could fix the
infix == function to compare metatypes instead the hash value.
What about dynamicType?
Any ideas?
--
Adrian Zubarev
Sent with Airmail
Am 13. Juli 2016 um 16:17:43, Anton Zhilin (antonyzhi...@gmail.com) schrieb:
2016-07-13 15:02 GMT+03:00 Adrian Zubarev via swift-evolution
<swift-evolution@swift.org>:
To answer your question, we still need the metatype to access initializer and
static member of that type. If we’d drop T.Type completely, we’d lose
functionality to do so.
protocol A {
init()
}
func foo<T : A>(metatype: T.Type) -> T {
return metatype.init()
}
In such cases, we can always refer to the type directly:
func foo<T : A>(metatype: Type<T>) -> T {
return T()
}
I would prefer to remove metatypes T.Type completely and replace them with your
somewhat transparent Type<T>.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
