[swift-evolution] MemoryLayout for a value

[Karl]

> On 6 Aug 2016, at 11:05, Adrian Zubarev via swift-evolution <swift-evolution at swift.org> 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…


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