<div dir="ltr">On Wed, Aug 3, 2016 at 8:47 PM, Erica Sadun via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</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 class="HOEnZb"><div class="h5">> On Aug 3, 2016, at 2:43 PM, Dave Abrahams via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br>
><br>
><br>
> Having seen the effects in the standard library and in other<br>
> code, I'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) -> MemoryLayout<T>.Type {<br>
> return MemoryLayout<T>.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<Int><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 ".of" at the use site is worth the<br>
> | added API complexity.<br>
> `----<br>
><br>
> Thoughts?<br>
> --<br>
> -Dave<br>
<br>
<br>
</div></div>I don't think using "of" is a great burden.<br></blockquote><div><br></div><div>Agreed, but I do think "memory layout of type of my value, size" is a mouthful compared to "size of value". Moreover, something doesn't sit right with me that MemoryLayout<T> and MemoryLayout.of(T.self) would be one and the same thing.</div><div><br></div><div>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:</div><div><br></div><div>```</div><div>extension MemoryLayout {</div><div> static func size(ofValue _: T) -> Int { return MemoryLayout.size }</div><div> // etc.</div><div>}</div><div>```</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class="HOEnZb"><font color="#888888"><br>
-- E<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">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>
</div></div></blockquote></div><br></div></div>