# SE-0322: Temporary Uninitialized Buffers

**URL:** <https://forums.swift.org/t/se-0322-temporary-uninitialized-buffers/51848>\
**Category:** Proposal Reviews\
**Created:** [September 7, 2021, 4:18pm UTC](https://forums.swift.org/t/se-0322-temporary-uninitialized-buffers/51848 "2021-09-07T16:18:36Z")\
**Posts on this page:** 1\
**Showing post:** 13

<div class="post-metadata">

**Author:** ![lorentey](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/lorentey/32/1299_2.png) [@lorentey](https://forums.swift.org/u/lorentey)\
**Post date:** [September 8, 2021, 3:53am UTC](https://forums.swift.org/t/se-0322-temporary-uninitialized-buffers/51848/13 "2021-09-08T03:53:37Z")

</div>

These look desirable, especially when interacting with low-level system APIs.

Is it okay to bake the stack vs heap limit into executables?

The names are what they are; they derive directly from our existing naming scheme for these sorts of constructs. FWIW, I find top-level `with…` functions are both undiscoverable (when I need them) and are too much in my face (when I don’t), at the same time. I think I’d prefer if we moved these as static functions under their corresponding types, [like @benrimmington suggested during the pitch](https://forums.swift.org/t/pitch-temporary-uninitialized-buffers/48954/29):

```swift
UnsafeMutableBufferPointer<Foo>.withEphemeral(capacity: 42) { buffer in … }
UnsafeMutableRawBufferPointer.withEphemeral(byteCount: 42, alignment: 8) { buffer in }
UnsafeMutablePointer<Foo>.withEphemeral { pointer in … }

```

The new functions are a good thematic fit with the existing `allocate` members, and tucking these away in the preexisting unsafe types would reduce concerns about adding even more top-level unsafe constructs to the stdlib.

---

_[View the full topic](https://forums.swift.org/t/se-0322-temporary-uninitialized-buffers/51848)._