[swift-evolution] MemoryLayout for a value

[David Sweeris]

> On Aug 4, 2016, at 13:31, Dave Abrahams via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
>> on Thu Aug 04 2016, Anton Zhilin <antonyzhilin-AT-gmail.com> wrote:
>> 
>> 2016-08-04 10:31 GMT+03:00 Xiaodi Wu via swift-evolution <
>> swift-evolution at swift.org>:
>> 
>>>> On Thu, Aug 4, 2016 at 2:29 AM, Karl <razielim at gmail.com> wrote:
>>>> 
>>>> It’s confusing because metatypes in Swift are pretty confusing in
>>>> general: Int.self returns Int.Type which is not the same as `type(of: <some
>>>> Int>)` (that would be Int).
>>>> 
>>>> If a novice wants to jump in, they’ll have to know that MemoryLayout(of:
>>>> Int.self) would return a MemoryLayout<Int.Type>.
>>> 
>>> Yes, here, I agree Dave is absolutely right. You and Dave have convinced
>>> me that neither `MemoryLayout(of: x)` nor `MemoryLayout.of(x)`, where x is
>>> an instance, would be appropriate.
>> 
>> Two weeks ago Adrian and I suggested adding dynamic 'size', 'stride',
>> 'alignment' to Mirror, which definition would look like:
>> 
>> public struct Mirror {
>>    internal metatype_: Any.Type
>> 
>>    public init<T>(_: T.Type)
>> 
>>    public var size: Int { get }
>>    public var stride: Int { get }
>>    public var align: Int { get }
>> 
>>    // ...
>> }
>> 
>> There are some problems with it right now, but I do believe that reflection
>> API is where dynamic `size`, `stride`, `alignment` belong.
> 
> I see your point, but that would unfortunately be an unacceptably
> expensive way to get that information.  Constructing a mirror is a
> nontrivial bit of work.

Two quick questions:
1) Can the expensive bits of mirrors be done lazily?
2) IIRC, the reflection API is supposed to be reworked for Swift 4. With that in mind, are mirrors likely to remain too be expensive to construct for this approach?

- Dave Sweeris