As I've said elsewhere, guaranteeing stack allocation is inherently dangerous, not just unsafe, which is why there's a heap fallback in the pitch. It's the same issue that C VLAs have. It may be sufficient to simply document something like:
This function allocates a temporary buffer. During optimization, stack promotion is performed and, because the buffer pointer has scoped access, can succeed more often than when using allocate(capacity:).
I'd also be content offering a function that only produces an UnsafeMutableRawBufferPointer and let callers deal with binding it to a type, if it would help ward folks off using this function too freely.
Not to shut down discussion but I think this level of implementation detail is tangential to the pitch process. The core team may agree, or they may disagree, or they may take a middle approach and say zeroing is on by default but can be turned off with a frontend flag or -Ofast or some such. Same with chkstk. Fair?
Thanks for taking this on. This has been an optimization that I have been looking forward to for a while now - Data and a few other Foundation overlay methods could get some really great benefits for having this (Data does one that is almost the same thing but is missing the compiler optimization on it). With what is proposed so far it seems like it would work for all the cases I can think of - we likely can improve the performance of Data, bridging, Strings (when it interacts with Foundation) and a number of other spots for both Darwin and Linux. For certain platforms I know there are bigger stack sizes in certain threads so perhaps an intelligent sizing might be something worth exploring.
@Michael_Gottesman has just pitched some new syntactic sugar for homogeneous tuples that, I think, addresses the desire above for fixed-size arrays in Swift.