# Pitch: Add a String Initializer with Access to Uninitialized Storage

**URL:** <https://forums.swift.org/t/pitch-add-a-string-initializer-with-access-to-uninitialized-storage/22611>\
**Category:** Pitches\
**Tags:** string\
**Created:** [April 4, 2019, 12:17am UTC](https://forums.swift.org/t/pitch-add-a-string-initializer-with-access-to-uninitialized-storage/22611 "2019-04-04T00:17:32Z")\
**Posts on this page:** 1\
**Showing post:** 2

<div class="post-metadata">

**Author:** ![Michael\_Ilseman](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/michael_ilseman/32/44640_2.png) [@Michael\_Ilseman](https://forums.swift.org/u/Michael_Ilseman)\
**Post date:** [April 4, 2019, 12:39am UTC](https://forums.swift.org/t/pitch-add-a-string-initializer-with-access-to-uninitialized-storage/22611/2 "2019-04-04T00:39:01Z")

</div>

> [@David\_Smith](#):
>
> # Add a String Initializer with Access to Uninitialized Storage

Woo! Huge +1

> [@David\_Smith](#):
>
> Bridging `NSString` to `String` currently requires using standard library internals to get good performance, which suggests a class of problem that the standard library is currently not well-equipped to solve: efficiently creating a `String` when you don't already have a contiguous buffer of bytes to initialize it with. In the `NSString` bridging case, that's using `CFStringGetBytes` to copy-and-transcode the contents of the `NSString` .

I think bridging undersells the motivation, it's generally useful and was included in [String Essentials](https://forums.swift.org/t/string-essentials/21909). It allows users to avoid having their own hacky buffers for small contents and avoids an extra allocation for large contents.

Within the standard library, [Float](https://github.com/apple/swift/blob/b3a2e40a0f71f085f8f0302676c377404ba12a02/stdlib/public/core/Runtime.swift.gyb#L166) and [Int](https://github.com/apple/swift/blob/b3a2e40a0f71f085f8f0302676c377404ba12a02/stdlib/public/core/Runtime.swift.gyb#L190) portions do the hacky stack buffers thing.

@ravikandhadai could probably make good use of this in his logging efforts, as might the server-side loggers. @johannesweiss, does NIO or other server side projects have a use for directly initializing strings?

@tbkka, would this be useful for Swift protobuf?

> [@David\_Smith](#):
>
> Unlike `Array` , there are no special considerations about the state of the buffer when an error is thrown.

Would this be because UTF8.CodeUnit is a trivial type? Worth stating explicitly.

> [@David\_Smith](#):
>
> ### Returning a `Bool` to indicate success from the closure
> 
> Requiring people to either `throw` or check in the caller for an empty `String` return if the initializing closure fails is slightly awkward, but again, not sufficiently so to warrant being inconsistent with `Array` .

The real motivation is that a failable closure would make the init failable. That would really hurt use sites, forcing them into an ugly anti-pattern the way failable `withContiguousStorageIfAvailable` often does in practice.

edit: removed dangling text

---

_[View the full topic](https://forums.swift.org/t/pitch-add-a-string-initializer-with-access-to-uninitialized-storage/22611)._