[Pitch] Temporary uninitialized buffers

[grynspan (Jonathan Grynspan)]

@fclout

Of course tacoCount is not a constant, but SOME_LIMIT in your original example hopefully is, given that variable-length arrays in C are problematic.

Either constant or known to the stdlib in some way—I have not attempted to define the heuristic here but in my POC branch it's a hard-coded 1KB.

@fclout

• You cannot return the result of withUnsafeUninitializedMutableBufferPointer , so I think that the concern of returning stackOfTacos is moot (aside from many other problematic aspects; if you need to return your array, then a stack-allocated array was probably not the right choice in the first place!).
• withUnsafeUninitializedBufferPointer is inherently not using a struct member, so I don't know why the ability to use fixed-size arrays as struct members would invalidate this construct.

That's my point: by adding a fixed-size array, you make these things possible, which forces the compiler to perform escape analysis, which is undecidable. The proposed function is, like all unsafe affordances in Swift, a way around that which is necessary in certain contexts (which have already been enumerated in this pitch thread.)

@fclout

Towards the last point: I'm asking because I am deeply skeptical that the cost of zeroing stack memory is unbearable in high-performance applications.

So, we're using initialization here to mean two things:

1. Zero-initialization, i.e. ensuring the raw bytes under the sequence are filled with zeroes (or 0xDEADBEEF or whatever), and
2. Swift value initialization, i.e. calling init(...) on every element in the sequence.

I think we're conflating these two definitions. I know I have done so previously in this thread, which is entirely my fault and I should know better. My bad!

Zero-initialization is likely cheap in many many cases and has benefits and I'm not questioning that. Swift value initialization, when it's solely for the purpose of satisfying the compiler's requirement that all values be initialized, is a performance cost with measurable impact on real-world codebases. It's also one you can avoid today by using UnsafeMutableBufferPointer.allocate(capacity:), but that comes with the cost of heap allocation unless you're lucky and the optimizer decides to stack promote (hint: it usually won't.)

@fclout

I agree that fixed-size arrays look like tuples, which is why I used a tuple-like syntax for them. However, last time this was brought up (several years ago), Joe mentioned that it would be problematic to have fixed-size arrays be too much like tuples because anonymous types can't have protocol conformances.

I think that's worth revisiting in a separate discussion, especially in light of a recent-ish pitch. It might be as "simple" as a new member function on tuples with same-typed values:

func withSequenceSemantics<R, S: Sequence>(_ body: (S) throws -> R) rethrows -> R where S.Element == Self.TypeOfAllValues

The syntax for that is all wrong but I'm sure you get the idea. In any case, I'd be happy to chat with both you and Joe about it in more detail.