[swift-evolution] MemoryLayout for a value

[Boris Wang]

Do you means a array of protocol P, rather than a array of element conform
with P?
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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160806/8ac510cf/attachment.html>