[swift-evolution] MemoryLayout for a value

[Dave Abrahams]

on Fri Aug 05 2016, Boris Wang <swift-evolution at swift.org> wrote:

> Addition:
>
> I think protocol should't has size, or it's size should be zero.
> Because you can't put the 40 bytes data in anywhere.

You certainly can.  If protocols didn't have a size, Array wouldn't be
able to store them.

>
>
> Boris Wang <kona.ming at gmail.com>于2016年8月6日 周六10:35写道：
>
>> codes in swift REPL:
>>
>> protocol P {
>> var x:Int {get}
>> }
>> MemoryLayout<P>.size
>> //r0 : Int = 40
>>
>> struct S1 {
>> var v1:Int = 0
>> }
>> MemoryLayout<S1>.size
>> //r1: Int =8
>>
>> struct S2: P {
>> var v2: Int
>> var x:Int
>> }
>> MemoryLayout <S2>.size
>> //r2: Int = 16
>>
>> ** Question:
>> Why we need to known the size of a object that can't be instanced?
>>
>> ** Confuse:
>> MemoryLayout <S2.Type>.size
>> //r3: Int = 0
>>
>> MemoryLayout <P.Type>.size
>> //r4: Int = 16
>>
>>
>>
>> Xiaodi Wu via swift-evolution <swift-evolution at swift.org>于2016年8月5日
>> 周五16:34写道：
>>
>>> On Thu, Aug 4, 2016 at 6:02 PM, Dave Abrahams <dabrahams at apple.com>
>>> wrote:
>>>
>>>>
>>>> on Thu Aug 04 2016, Dmitri Gribenko <gribozavr-AT-gmail.com> wrote:
>>>>
>>>> > On Wed, Aug 3, 2016 at 7:28 PM, Xiaodi Wu via swift-evolution
>>>> > <swift-evolution at swift.org> wrote:
>>>> >> Could I suggest an alternative? It's conservative in that it mimics
>>>> the
>>>> >> relationships we had before the proposal was implemented and also
>>>> maintains
>>>> >> the simplicity of the caseless enum:
>>>> >>
>>>> >> ```
>>>> >> extension MemoryLayout {
>>>> >>   static func size(ofValue _: T) -> Int { return MemoryLayout.size }
>>>> >>   // etc.
>>>> >> }
>>>> >> ```
>>>> >
>>>> > I like this API.  I think given all the alternatives that we explored,
>>>> > it is better than those.  I also think that it nicely avoids the
>>>> > following issue with the proposed MemoryLayout.of(type(of:
>>>> > someExpression)).size syntax.
>>>> >
>>>> > Imagine that you have a value whose static type differs from the
>>>> > dynamic type.  For example, a protocol existential:
>>>> >
>>>> > protocol P {}
>>>> > extension Int : P {}
>>>> > var x: P = 10
>>>> >
>>>> > The question is, what does MemoryLayout.of(type(of: x)).size compute,
>>>> > size of the existential box, or the size of an Int instance?  The
>>>> > semantics of 'type(of:)' are "return the dynamic type", so the
>>>> > straightforward conclusion is that MemoryLayout.of(type(of: x)).size
>>>> > returns the size of the dynamic type instance, of Int.
>>>> >
>>>> > What actually happens is that 'type(of: x)' returns a dynamic value of
>>>> > 'Int.self', statically typed as 'P.Type'.  So P gets deduced for the
>>>> > generic parameter of MemoryLayout, and MemoryLayout.of(type(of:
>>>> > x)).size returns the size of the protocol box.
>>>> >
>>>> > I think due to this complex interaction, using type(of:) might lead to
>>>> > confusing code, and thus I like Xiaodi's approach better.
>>>> >
>>>> > Dmitri
>>>>
>>>> Okay, I'm convinced; that's what we should do.
>>>>
>>>
>>> Proposal and stdlib PRs have both been created.
>>>
>>>
>>>> --
>>>> -Dave
>>>>
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>
>>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>

-- 
-Dave