+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 <[email protected]>于2016年8月6日 周六23:23写道： > > 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 >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
