[swift-evolution] MemoryLayout for a value

Boris Wang kona.ming at gmail.com
Sat Aug 6 17:38:04 CDT 2016


+1

* I think swift expose too much informations inside compiler to the user。

* I can't imagine, a modern, swift language can't get the size of T/t with
same API:
MemoryLayout<T>.size
MemoryLayout.size(ofValue:t)



Karl via swift-evolution <swift-evolution at swift.org>于2016年8月6日 周六23:23写道:

>
> 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…
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160806/2c9bf830/attachment.html>


More information about the swift-evolution mailing list