2016-07-13 20:19 GMT+03:00 Adrian Zubarev via swift-evolution < swift-evolution@swift.org>: > > Am 13. Juli 2016 um 18:30:53, Anton Zhilin (antonyzhi...@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.
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution