[swift-evolution] MemoryLayout for a value

[Dave Abrahams]

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

> Do you means a array of protocol P, rather than a array of element conform
> with P?

Yes.

> Dave Abrahams via swift-evolution
> <swift-evolution at swift.org>于2016年8月6日
> 周六13:22写道：
>
>>
>> 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
>>
>> _______________________________________________
>> 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