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

[Adrian Zubarev]

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 (antonyzhilin at gmail.com) schrieb:

2016-07-13 15:02 GMT+03:00 Adrian Zubarev via swift-evolution <swift-evolution at 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>.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160713/7da82c4c/attachment.html>