<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=""><br class=""><div><blockquote type="cite" class=""><div class="">On 17 Apr 2017, at 23:18, Michael Ilseman via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">This is the best approach that I’m aware of. It does bake in an ABI assumption that the tuple layout will be contiguous and strided/addressable. Monitor <a href="https://bugs.swift.org/browse/SR-3726" class="">https://bugs.swift.org/browse/SR-3726</a> for changes here. Note that you can also a little more “pure” in a sense if you construct an UnsafeBufferPointer from your UnsafeRawPointer and operate on that. Currently, the compiler does not always elide the copy in the getter, see <a href="https://bugs.swift.org/browse/SR-4581" class="">https://bugs.swift.org/browse/SR-4581</a></div><div class=""><br class=""></div></div></div></blockquote></div><br class=""><div class="">Will the compiler ever optimise an UBP allocation on to the stack? For example, I’ve written plenty of code such as:</div><div class=""><br class=""></div><div class="">let ptr = UnsafeRawBufferPointer.allocate(count: 128)</div><div class="">defer { ptr.deallocate(count: 128) }</div><div class=""><br class=""></div><div class="">...when interfacing with C APIs. Which is basically the definition of a stack allocation. That would perhaps be the “swiftier” way to do it; to let the compiler determine how to allocate the memory based on what it knows about its expected lifetime.</div></body></html>