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

[Adrian Zubarev]

Am 13. Juli 2016 um 18:30:53, Anton Zhilin (antonyzhilin at gmail.com) schrieb:

I see model of Type<T> as follows:
Values of Type<T> are identifiers of types (8 bytes, I guess)
All used identifiers are contained in Type<Any>
Type<T> contains a subset of those identifiers
I can’t follow your though here. Is this a totally new behavior?

Type<T> are usually created with default constructor Type<T>()
That one is easy and already there.

Upcasting uses constructor init<U: T>(upcasting: Type<U>)
It does look neat but I can’t implement it. At least I have no clue how to solve the problem that `T` is not a protocol or a class type.

Checking for conformance uses method isSubtype(of:)
Interesting suggestion.

Size of Type<Type<T>> is 8, static size of Type<SomeProtocol> is 0
I feel like you mean something different here than this:

```swift

protocol SomeProtocol {}

sizeof(SomeProtocol.self) == 40
```

2016-07-13 18:25 GMT+03:00 Adrian Zubarev via swift-evolution <swift-evolution at swift.org>:
a = SomeClass.self

expectTrue(a as? Any.Type == SomeClass.self)
expectTrue(a as? AnyClass == SomeClass.self)
expectTrue(a as? SomeClass.Type == SomeClass.self)
That example just demonstrates syntax of metatypes and does not count.
What about dynamicType?

It should have the following signature:

func dynamicType<T>(_ var: T) -> Type<T>

To return Type<T> means to return an identifier of U: T
Was this a typo?

func dynamicType<U: T>(_ var: T) -> Type<U>

PS: If you’d like to join on this idea, I could move the draft to a repo to be able to write the proposal together. You had some good catchy ideas there.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160713/42441435/attachment.html>