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

[Anton Zhilin]

2016-07-13 20:19 GMT+03:00 Adrian Zubarev via swift-evolution <
swift-evolution at swift.org>:
>
> Am 13. Juli 2016 um 18:30:53, Anton Zhilin (antonyzhilin at gmail.com)
> schrieb:
>
> I see model of Type<T> as follows:
>
>    1. Values of Type<T> are identifiers of types (8 bytes, I guess)
>    2. All used identifiers are contained in Type<Any>
>    3. Type<T> contains a subset of those identifiers
>
> I can’t follow your though here. Is this a totally new behavior?
>
That's how it works right now:

sizeofValue(Bool.self)              //=> 0 (optimized away)
sizeofValue(Bool.self as Any.self)  //=> 8

I'll put my thoughts another way:

   - Internally, Type<T> contains an Int, i.e. identifer of a type. For
   every type, compiler must choose a different identifier
   - API of Type<T> is defined so that it can only contain identifiers of
   subtypes of T
   - For example, when you get a variable of Type<BaseClass>, it can
   correspond to BaseClass or DerivedClass


>    1. 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.
>
We should add implicit convertion of Type<U> to Type<T>, dulicating current
behaviour of `as T.Type`.
That constructor still can be useful, but it will be failable and not that
significant in practise.
I don't like adding compiler magic, but I guess we really should in this
case, because otherwise Type<T> can't replace T.Type.

>
>    1. 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
>
> ```
>

That was a mistake. Static size of Type<SomeProtocol> will be 40, and size
property of its values can be less or greater than 40, depending on
internal type identifier.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160713/caaf4389/attachment.html>