SE-0322: Temporary Uninitialized Buffers

[Karl]

@Joe_Groff

First of all, we agree that this is useful functionality for programmers who need stronger behavior guarantees from their code than the existing language can currently provide. Although in some circumstances the compiler can optimize heap allocations into stack allocations, and the optimizer will continue to improve in time, it is valuable to have an API that can guarantee that stack allocation occurs in more circumstances.

The issue I have with this approach is that it is a long-standing deficiency of the optimiser. Here's a post I made back in 2017 about exactly this:

Swift needs fixed-size array

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.

···

On 17 Apr 2017, at 23:18, Michael I…

And it has come up many, many times since then. Not to be too harsh on the optimiser here, but looking over the last 4 years, it seems that promoting heap allocations on to the stack just has not been a priority, and even obvious candidates for promotion still allocate on the heap.

I'm worried that by introducing a new API, that optimisation potential is going to continue to be ignored, because it gives us an easy excuse - to just use this other API instead. IMO, in a high-level language, you write what you mean, and the compiler's job is to make it fast. Requiring specific APIs in order to opt-in to stack allocation feels clunky and outdated - it's an obvious win, as obvious as anything else the optimiser does - and you shouldn't need to opt-in to it with special APIs. That's not to mention all of the existing code which would automatically benefit from a smarter optimiser.

For the specific API pitched, my opinion is that we should first improve the optimiser, and then discuss whether there is still a need for additional APIs.

@Joe_Groff

The Core Team believes that, for applications that require maximum predictability, these APIs should provide an optional parameter for the maximum stack allocation threshold , for fully predictable behavior.

This is more interesting; particular the part about wanting fully predictable behaviour. Obviously, letting developers control when stack allocation happens means there is a risk of stack overflow, which is generally undefined behaviour, and unlike buffer over-reads or use-after-frees, developers cannot easily predict when that will happen. Basically that would be VLAs.

If we did want to add APIs to support stack allocation beyond what an improved optimiser can provide, I think there might be room for an allocation function which attempts to allocate on the stack and returns an optional, making use of the fact that many platforms provide "checked" alternatives to alloca which notify the caller of the failure.

The actual functionality to "allocate on the stack if possible, otherwise go to the heap" should be an optimisation which all developers can rely on using the existing APIs.