on Sat Aug 06 2016, Boris Wang <[email protected]> wrote: > Do you means a array of protocol P, rather than a array of element conform > with P?
Yes. > Dave Abrahams via swift-evolution > <[email protected]>于2016年8月6日 > 周六13:22写道： > >> >> on Fri Aug 05 2016, Boris Wang <[email protected]> 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 <[email protected]>于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 >> >> <[email protected]>于2016年 >> >> 8月5日 >> >> 周五16:34写道： >> >> >> >>> On Thu, Aug 4, 2016 at 6:02 PM, Dave Abrahams <[email protected]> >> >>> 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 >> >>>> > <[email protected]> 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 >> >>> [email protected] >> >>> https://lists.swift.org/mailman/listinfo/swift-evolution >> >>> >> >> >> > _______________________________________________ >> > swift-evolution mailing list >> > [email protected] >> > https://lists.swift.org/mailman/listinfo/swift-evolution >> > >> >> -- >> -Dave >> >> _______________________________________________ >> 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 > -- -Dave _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
