<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div><blockquote type="cite" class=""><div class="">On Jun 2, 2016, at 8:48 AM, Matthew Johnson via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>&gt; wrote:</div><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><blockquote type="cite" class=""><div class="">On Jun 2, 2016, at 10:38 AM, Xiaodi Wu &lt;<a href="mailto:xiaodi.wu@gmail.com" class="">xiaodi.wu@gmail.com</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class=""><div style="white-space:pre-wrap" class="">Well, as I understand it, it's not actually possible to write your own type(of:), so we're going from a "magic" property to a "magic" function at least for now.</div></div></blockquote><div class=""><br class=""></div><div class="">No, but you *can* write `func foo&lt;T&gt;(_ t: T)` which accepts any value (you *cannot* write a property that is available for all properties - that would require the ability to write `extension Any`. &nbsp;This is the distinction I am making. &nbsp;Of course the implementation is compiler magic no matter how we express it syntactically. &nbsp;But we can make it *appear* just like it might if the implementation *wasn’t* compiler magic. &nbsp;That makes it fit into the language better IMO and was the biggest motivator for changing `dynamicType`.</div><div class=""><br class=""></div><blockquote type="cite" class=""><div class=""><div style="white-space:pre-wrap" class=""><br class="">I'm most alarmed that one implication of the MemoryLayout proposal is loss of the `ofValue` family of functions. These functions don't fit with the design: imagine, what is `MemoryLayout&lt;Double&gt;.size(ofValue: Float(42))`? But the response seems to be that these functions don't seem necessary at all and should be removed. "I don't see a use for it" is an insufficient justification for a feature removal. Looking to other languages, C# has sizeof as a static property but tellingly offers the equivalent of sizeofValue (well, strideofValue) as a function in a different module. Essentially every other C-family language that exposes pointers to the user offers both of and ofValue equivalents. The question is, how does a user with existing code using sizeofValue() migrate to Swift 3? I do not see a viable answer with the MemoryLayout design.<br class=""></div></div></blockquote><div class=""><br class=""></div><div class="">Going with MemoryLayout *does not* mean we would have to give up the value functions if we don’t want to:</div><div class=""><br class=""></div><div class="">struct MemoryLayout&lt;T&gt; {</div><div class="">&nbsp; &nbsp; init() {}</div><div class="">&nbsp; &nbsp; init(t: T) { /* throw away the value */ }</div><div class="">&nbsp; &nbsp;&nbsp;</div><div class="">&nbsp; &nbsp; // we could omit the static properties and require&nbsp;</div><div class="">&nbsp; &nbsp; // writing MemoryLayout&lt;Int&gt;() if we don’t like the duplication</div><div class="">&nbsp; &nbsp; static let size: Int</div><div class="">&nbsp; &nbsp; static let spacing: Int</div><div class="">&nbsp; &nbsp; static let alignment: Int</div><div class=""><br class=""></div><div class=""><div class="">&nbsp; &nbsp; let size: Int</div><div class="">&nbsp; &nbsp; let spacing: Int</div><div class="">&nbsp; &nbsp; let alignment: Int</div></div><div class="">}</div><div class=""><br class=""></div><div class="">let size = MemoryLayout&lt;Int&gt;.size</div><div class="">let sizeOfValue = MemoryLayout(42).size</div></div></div></div></blockquote><div><br class=""></div>There's no good reason for this type to be generic. &nbsp;It should be non-generic and require the use of the instance properties.</div><div><br class=""></div><div>It's actively harmful for this type to appear to be computed from a value. &nbsp;The layout is not in any way tied to the dynamic type of the value — for example, it is not the instance layout of the most-derived class or the value layout of the dynamic type of an existential. &nbsp;Furthermore, saying that it is computed from a value means that attempting to compute it from a type will succeed using the layout of the metatype, which seems like a catastrophic failure of API design.</div><div><br class=""></div><div>John.</div><div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><br class=""><blockquote type="cite" class=""><div class=""><br class=""><div class="gmail_quote"><div dir="ltr" class="">On Thu, Jun 2, 2016 at 8:03 AM Matthew Johnson &lt;<a href="mailto:matthew@anandabits.com" class="">matthew@anandabits.com</a>&gt; wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto" class=""><div class=""><span class=""></span></div><div class=""><div class=""><br class=""><br class="">Sent from my iPad</div></div></div><div dir="auto" class=""><div class=""><div class=""><br class="">On Jun 2, 2016, at 12:27 AM, Xiaodi Wu via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>&gt; wrote:<br class=""><br class=""></div><blockquote type="cite" class=""><div class=""><div dir="ltr" class="">On Thu, Jun 2, 2016 at 12:24 AM, Patrick Smith <span dir="ltr" class="">&lt;<a href="mailto:pgwsmith@gmail.com" target="_blank" class="">pgwsmith@gmail.com</a>&gt;</span> wrote:<br class=""><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><div class="">I really like this idea. This IMO is lower level functionality than `type(of:)` (née dynamicType), so I think it makes sense for it to be grouped under its own domain, the MemoryLayout type.</div><div class=""><br class=""></div><div class="">Plus MemoryLayout can be extended with new convenience methods.</div><div class=""><br class=""></div><div class="">I’m fine with those old methods being removed, but I never use them so! Is it the same as calling type(of:) then using that with MemoryLayout? I imagine they could be fixit’d easily, and that they compile down to the same underlying code.</div></div></blockquote><div class=""><br class=""></div><div class="">I'm actually souring to the idea. It goes in the diametrically opposite direction from dynamicType. There, something was changed from being property-like to being function-like. Here, Dave's proposal would take something that's a function and turn it into a property. Hmm.</div></div></div></div></div></blockquote><div class=""><br class=""></div></div></div><div dir="auto" class=""><div class=""><div class="">That's not a fair comparison though.&nbsp; With dynamicType we removed a "magic" property visible on all types, which isn't something you can write and turned it into a function (which is obviously something you can write). &nbsp;</div><div class=""><br class=""></div><div class="">Dave's MemoryLayout creates a new type to bundle together related items which makes their semantic relationship more clear.&nbsp; It also receives the type via a generic argument rather than a function argument and makes the properties static.&nbsp; That is more representative of what is actually happening and could help to prevent confusion. &nbsp;</div><div class=""><br class=""></div><div class="">If we really need an 'ofValue' option that infers T from a value the properties on MemoryLayout could also be made available as instance properties and it could have an initializer that accepts an instance to T and throws the value away.&nbsp; However, I'm not at all convinced this is necessary.</div></div></div><div dir="auto" class=""><div class=""><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><span class=""><div class=""><blockquote type="cite" class=""><div class="">On 2 Jun 2016, at 3:05 PM, Xiaodi Wu via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>&gt; wrote:</div><br class=""><div class=""><div class="gmail_extra" style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">2. Dave A. and others expressed the opinion that these should probably not be global functions; his preference was for:</div><div class="gmail_extra" style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><br class=""></div><div class="gmail_extra" style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">```</div><div class="gmail_extra" style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">MemoryLayout&lt;T&gt;.size // currently sizeof()</div><div class="gmail_extra" style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">MemoryLayout&lt;T&gt;.spacing // currently strideof()</div><div class="gmail_extra" style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">MemoryLayout&lt;T&gt;.alignment // currently alignof()</div><div class="gmail_extra" style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">```</div><div class="gmail_extra" style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><br class=""></div><div class="gmail_extra" style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">3. Dave A. proposed that sizeofValue(), strideofValue(), and alignofValue() are better off removed altogether. I don't know if people are going to be happy about this idea.</div></div></blockquote></div><br class=""></span></div></blockquote></div><br class=""></div></div>
</div></blockquote></div></div><div dir="auto" class=""><div class=""><blockquote type="cite" class=""><div class=""><span class="">_______________________________________________</span><br class=""><span class="">swift-evolution mailing list</span><br class=""><span class=""><a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a></span><br class=""><span class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br class=""></div></blockquote></div></div></blockquote></div>
</div></blockquote></div><br class=""></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></body></html>