My understanding is that there is no mechanism yet to guarantee stack allocation for anything.
> On Apr 17, 2017, at 3:29 PM, Karl Wagner <[email protected]> wrote: > > >> On 17 Apr 2017, at 23:18, Michael Ilseman via swift-evolution >> <[email protected] <mailto:[email protected]>> wrote: >> >> 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 https://bugs.swift.org/browse/SR-3726 >> <https://bugs.swift.org/browse/SR-3726> 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 >> https://bugs.swift.org/browse/SR-4581 <https://bugs.swift.org/browse/SR-4581> >> > > Will the compiler ever optimise an UBP allocation on to the stack? For > example, I’ve written plenty of code such as: > > let ptr = UnsafeRawBufferPointer.allocate(count: 128) > defer { ptr.deallocate(count: 128) } > > ...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.
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
