<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>MemoryLayout is reminiscent of how of how mirror types are wrap around underlying data they represent... so that would add to the regularity if the runtime lib. Not to mention there are precedents outside swift.</div><div><br>On Jun 2, 2016, at 5:56 PM, Xiaodi Wu via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br><br></div><blockquote type="cite"><div><div style="white-space:pre-wrap">Both good points. I could live with your solution.<br></div><br><div class="gmail_quote"><div dir="ltr">On Thu, Jun 2, 2016 at 10:48 AM Matthew Johnson <<a href="mailto:matthew@anandabits.com">matthew@anandabits.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><blockquote type="cite"><div>On Jun 2, 2016, at 10:38 AM, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" target="_blank">xiaodi.wu@gmail.com</a>> wrote:</div><br><div><div style="white-space:pre-wrap">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><br></div></div></div><div style="word-wrap:break-word"><div><div>No, but you *can* write `func foo<T>(_ 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`. This is the distinction I am making. Of course the implementation is compiler magic no matter how we express it syntactically. But we can make it *appear* just like it might if the implementation *wasn’t* compiler magic. That makes it fit into the language better IMO and was the biggest motivator for changing `dynamicType`.</div></div></div><div style="word-wrap:break-word"><div><div><br></div><blockquote type="cite"><div><div style="white-space:pre-wrap"><br>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<Double>.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></div></div></blockquote><div><br></div></div></div><div style="word-wrap:break-word"><div><div>Going with MemoryLayout *does not* mean we would have to give up the value functions if we don’t want to:</div><div><br></div><div>struct MemoryLayout<T> {</div><div> init() {}</div><div> init(t: T) { /* throw away the value */ }</div><div> </div><div> // we could omit the static properties and require </div><div> // writing MemoryLayout<Int>() if we don’t like the duplication</div><div> static let size: Int</div><div> static let spacing: Int</div><div> static let alignment: Int</div><div><br></div><div><div> let size: Int</div><div> let spacing: Int</div><div> let alignment: Int</div></div><div>}</div><div><br></div><div>let size = MemoryLayout<Int>.size</div><div>let sizeOfValue = MemoryLayout(42).size</div></div></div><div style="word-wrap:break-word"><div><br><blockquote type="cite"><div><br><div class="gmail_quote"><div dir="ltr">On Thu, Jun 2, 2016 at 8:03 AM Matthew Johnson <<a href="mailto:matthew@anandabits.com" target="_blank">matthew@anandabits.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div><span></span></div><div><div><br><br>Sent from my iPad</div></div></div><div dir="auto"><div><div><br>On Jun 2, 2016, at 12:27 AM, Xiaodi Wu via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr">On Thu, Jun 2, 2016 at 12:24 AM, Patrick Smith <span dir="ltr"><<a href="mailto:pgwsmith@gmail.com" target="_blank">pgwsmith@gmail.com</a>></span> wrote:<br><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"><div>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><br></div><div>Plus MemoryLayout can be extended with new convenience methods.</div><div><br></div><div>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><br></div><div>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><br></div></div></div><div dir="auto"><div><div>That's not a fair comparison though. 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). </div><div><br></div><div>Dave's MemoryLayout creates a new type to bundle together related items which makes their semantic relationship more clear. It also receives the type via a generic argument rather than a function argument and makes the properties static. That is more representative of what is actually happening and could help to prevent confusion. </div><div><br></div><div>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. However, I'm not at all convinced this is necessary.</div></div></div><div dir="auto"><div><br><blockquote type="cite"><div><div dir="ltr"><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"><span><div><blockquote type="cite"><div>On 2 Jun 2016, at 3:05 PM, Xiaodi Wu via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:</div><br><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">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></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<T>.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<T>.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<T>.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></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></span></div></blockquote></div><br></div></div>
</div></blockquote></div></div><div dir="auto"><div><blockquote type="cite"><div><span>_______________________________________________</span><br><span>swift-evolution mailing list</span><br><span><a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></div></blockquote></div></div></blockquote></div>
</div></blockquote></div></div></blockquote></div>
</div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>swift-evolution mailing list</span><br><span><a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></div></blockquote></body></html>