> On 6 Aug 2016, at 11:05, Adrian Zubarev via swift-evolution > <[email protected]> wrote: > > What’s so confusing about MemoryLayout<T.Type>.size? > > size in this context gives you the size for the metatype of T, not the size > of T. > > If I memorize correctly: > > Size of metatypes of value types and functions/closures is 0. > Size for class metatypes is 8. > Size for protocols metatypes (in your case it’s P.Protocol, not P.Type) is 16 > except for the (old) empty protocol Any which is 8. > You may ask why these metatypes have these sizes?! I can’t answer this > question, because I don’t know the technical reason, but it doesn’t matter in > our case. > > Furthermore there is a difference between T.Type and what you get from T.self. > > T.self returns a concrete metatype for T. T.Type is a metatype supertype for > all subtypes of T if there exist a subtype relationship. > > That’s why something like this works fine: > > let a1: Any.Type = Int.self // `Int.self` is 0 where `Any.self` is 8 > let a2: Any.Type = P.self // same story with different sizes > We’re revising our proposal to provide a clear distinction of this behavior > and get rid of .Protocol and .Type. > >
I think the underlying issue isn’t that MemoryLayout<T> vs MemoryLayout<T.Type> is confusing, it’s that our metatype system is a little awkward, so the way you construct a MemoryLayout<X> can lead to non-obvious results unless you’re an expert. Given time constraints, the most practical solution which gives us the best product for Swift 3.0 is to revise the MemoryLayout interface, but I think most users would be happy to see some simplification of the metatype system for Swift >3.0. Personally I only sporadically remember which name means what in a given context. Oh, the dark corners I would have been lost in without code-completion…
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
