<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">2016-08-05 16:20 GMT+09:00 Xiaodi Wu <span dir="ltr">&lt;<a href="mailto:xiaodi.wu@gmail.com" target="_blank">xiaodi.wu@gmail.com</a>&gt;</span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><span>On Fri, Aug 5, 2016 at 2:06 AM, rintaro ishizaki <span dir="ltr">&lt;<a href="mailto:fs.output@gmail.com" target="_blank">fs.output@gmail.com</a>&gt;</span> wrote:<br></span><div class="gmail_quote"><span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><span><div style="font-size:14px">&gt; ```</div><div style="font-size:14px">&gt; extension MemoryLayout {</div><div style="font-size:14px">&gt;   static func size(ofValue _: T) -&gt; Int { return MemoryLayout.size }</div><div style="font-size:14px">&gt;   // etc.</div><div style="font-size:14px">&gt; }</div><div>&gt; ```</div><div><br></div></span><div><div>I don&#39;t think we can do this while we have:</div><div><br></div></div><div><div><font face="monospace, monospace">  public static var size: Int {</font></div></div></div></blockquote><div><br></div></span><div>Why not?</div></div></div></div></blockquote><div><br></div><div>My bad. Sorry, never mind. </div><div>I didn&#39;t know we can have such overloads (property and func, same basename) :O</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">maybe `<span style="font-size:14px"><font face="monospace, monospace">sizeOf(value _: T) -&gt; Int</font></span>` ?<div><br></div></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">2016-08-04 11:28 GMT+09:00 Xiaodi Wu via swift-evolution <span dir="ltr">&lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt;</span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div>On Wed, Aug 3, 2016 at 8:47 PM, Erica Sadun via swift-evolution <span dir="ltr">&lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt;</span> wrote:<br></div></div><div class="gmail_extra"><div class="gmail_quote"><div><div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div>&gt; On Aug 3, 2016, at 2:43 PM, Dave Abrahams via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt; wrote:<br>
&gt;<br>
&gt;<br>
&gt; Having seen the effects in the standard library and in other<br>
&gt; code, I&#39;m concerned that we may have made a mistake in removing<br>
&gt; `sizeofValue` et al without providing a replacement.  In the standard<br>
&gt; library, we ended up adding an underscored API that allows<br>
&gt;<br>
&gt;  MemoryLayout._ofInstance(someE<wbr>xpression).size<br>
&gt;<br>
&gt; Where someExpression is an autoclosure, and thus not evaluated.  I<br>
&gt; wanted to bring up the possibility of introducing a replacement as a<br>
&gt; bufix.<br>
&gt;<br>
&gt; I propose that the way to express the above should be:<br>
&gt;<br>
&gt;  MemoryLayout.of(type(of: someExpression)).size<br>
&gt;<br>
&gt; implementable as:<br>
&gt;<br>
&gt;  extension MemoryLayout {<br>
&gt;    @_transparent<br>
&gt;    public<br>
&gt;    static func of(_: T.Type) -&gt; MemoryLayout&lt;T&gt;.Type {<br>
&gt;      return MemoryLayout&lt;T&gt;.self<br>
&gt;    }<br>
&gt;  }<br>
&gt;<br>
&gt; I think this API would solve the concerns I had about confusability that<br>
&gt; led me to advocate dropping the ability to ask for the size of a value.<br>
&gt; The only way to use it is to pass a type and these two expressions have<br>
&gt; equivalent meaning:<br>
&gt;<br>
&gt;    MemoryLayout&lt;Int&gt;<br>
&gt;    MemoryLayout.of(Int.self)<br>
&gt;<br>
&gt; It also has the benefit of isolating the autoclosure magic to type(of:).<br>
&gt;<br>
&gt; ,----[ Aside ]<br>
&gt; | A slightly cleaner use site is possible with a larger API change:<br>
&gt; |<br>
&gt; |   MemoryLayout(type(of: someExpression)).size<br>
&gt; |<br>
&gt; | Which would involve changing MemoryLayout from an `enum` to<br>
&gt; | a `struct` and adding the following:<br>
&gt; |<br>
&gt; |   extension MemoryLayout {<br>
&gt; |     public init(_: T.Type) {}<br>
&gt; |<br>
&gt; |     public var size: Int { return MemoryLayout.size }<br>
&gt; |     public var stride: Int { return MemoryLayout.stride }<br>
&gt; |     public var alignment: Int { return MemoryLayout.alignment }<br>
&gt; |   }<br>
&gt; |<br>
&gt; | However I am concerned that dropping &quot;.of&quot; at the use site is worth the<br>
&gt; | added API complexity.<br>
&gt; `----<br>
&gt;<br>
&gt; Thoughts?<br>
&gt; --<br>
&gt; -Dave<br>
<br>
<br>
</div></div>I don&#39;t think using &quot;of&quot; is a great burden.<br></blockquote><div><br></div></div></div><div>Agreed, but I do think &quot;memory layout of type of my value, size&quot; is a mouthful compared to &quot;size of value&quot;. Moreover, something doesn&#39;t sit right with me that MemoryLayout&lt;T&gt; and MemoryLayout.of(T.self) would be one and the same thing.</div><div><br></div><div>Could I suggest an alternative? It&#39;s conservative in that it mimics the relationships we had before the proposal was implemented and also maintains the simplicity of the caseless enum:</div><div><br></div><div>```</div><div>extension MemoryLayout {</div><div>  static func size(ofValue _: T) -&gt; Int { return MemoryLayout.size }</div><div>  // etc.</div><div>}</div><div>```</div><span><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span><font color="#888888"><br>
-- E<br>
</font></span><div><div><br>
______________________________<wbr>_________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailma<wbr>n/listinfo/swift-evolution</a><br>
</div></div></blockquote></span></div><br></div></div>
<br>______________________________<wbr>_________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailma<wbr>n/listinfo/swift-evolution</a><br>
<br></blockquote></div><br></div>
</div></div></blockquote></div></div></div><br></div></div>
</blockquote></div><br></div></div>