Pitch: Add a String Initializer with Access to Uninitialized Storage

[Michael_Ilseman]

@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. 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 and Int 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