Why not just MemoryLayout.init(of instance: T), and drop the autoclosure magic altogether?<br><br>The classic sizeofValue evaluated its argument, and in Foundation several uses of it actually relied on that side effect. While autoclosures are quite clever, in general I think the user expectation is that given `a(b(c))` both a and b are invoked, side effects and all.<br><br>Note that both type(of:) as it&#39;s currently implemented and the old dynamicType evaluate its argument/receiver. No one afaik has ever thought that behavior to be anomalous (though I bet we&#39;re about to hear some arguments to that effect now).<br><div class="gmail_quote"><div dir="ltr">On Wed, Aug 3, 2016 at 15:46 Dave Abrahams via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
Having seen the effects in the standard library and in other<br>
code, I&#39;m concerned that we may have made a mistake in removing<br>
`sizeofValue` et al without providing a replacement.  In the standard<br>
library, we ended up adding an underscored API that allows<br>
<br>
  MemoryLayout._ofInstance(someExpression).size<br>
<br>
Where someExpression is an autoclosure, and thus not evaluated.  I<br>
wanted to bring up the possibility of introducing a replacement as a<br>
bufix.<br>
<br>
I propose that the way to express the above should be:<br>
<br>
  MemoryLayout.of(type(of: someExpression)).size<br>
<br>
implementable as:<br>
<br>
  extension MemoryLayout {<br>
    @_transparent<br>
    public<br>
    static func of(_: T.Type) -&gt; MemoryLayout&lt;T&gt;.Type {<br>
      return MemoryLayout&lt;T&gt;.self<br>
    }<br>
  }<br>
<br>
I think this API would solve the concerns I had about confusability that<br>
led me to advocate dropping the ability to ask for the size of a value.<br>
The only way to use it is to pass a type and these two expressions have<br>
equivalent meaning:<br>
<br>
    MemoryLayout&lt;Int&gt;<br>
    MemoryLayout.of(Int.self)<br>
<br>
It also has the benefit of isolating the autoclosure magic to type(of:).<br>
<br>
,----[ Aside ]<br>
| A slightly cleaner use site is possible with a larger API change:<br>
|<br>
|   MemoryLayout(type(of: someExpression)).size<br>
|<br>
| Which would involve changing MemoryLayout from an `enum` to<br>
| a `struct` and adding the following:<br>
|<br>
|   extension MemoryLayout {<br>
|     public init(_: T.Type) {}<br>
|<br>
|     public var size: Int { return MemoryLayout.size }<br>
|     public var stride: Int { return MemoryLayout.stride }<br>
|     public var alignment: Int { return MemoryLayout.alignment }<br>
|   }<br>
|<br>
| However I am concerned that dropping &quot;.of&quot; at the use site is worth the<br>
| added API complexity.<br>
`----<br>
<br>
Thoughts?<br>
--<br>
-Dave<br>
<br>
_______________________________________________<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/mailman/listinfo/swift-evolution</a><br>
</blockquote></div>