SE-0263 (review #2): Add a String Initializer with Access to Uninitialized Storage

[tkremenek (Ted Kremenek)]

The requested revisions to SE-0263 have been made to the proposal:

@tkremenek

The proposal has been accepted, with the request that the proposal author revises the API name to include "unsafe". This was brought up during the review discussion, and the Core Team agreed this was an important aspect to include in the API's name.

Please see the updated review proposal:

apple/swift-evolution/blob/main/proposals/0263-string-uninitialized-initializer.md

The review will resume and continue until October 14 to allow the community to have a chance to discuss the API change.

[lukasa (Cory Benfield)]

+1. This addresses my concerns from the previous pitch thread, and I am now happy with this proposal. Thanks so much @David_Smith, and everyone who helped on the original review thread.

[Karl]

+1

This nit remains from the previous version of the proposal:

The new initializer takes a closure that operates on an UnsafeMutableBufferPointer and an inout count of initialized elements.

No it doesn’t.

Also, I’d very much appreciate if we could back-deploy this API to older versions of the standard library. Doing so would result in cleaner, less spaghetti-like code for users of this initialiser. iOS 13/Catalina just shipped, so it’ll be years before we can raise our minimum deployment targets above Swift 5.1.

As for that back-deployed version, I think we probably can do better than what the user would do manually. Even if for some reason we can't provide the closure with a pointer to _StringGuts's internal buffer, we could do something like:

• If the requested capacity is small enough for a small-string, do a stack allocation like Int/Float already do and give a pointer to that.
• If the requested capacity is large, allocate an object and use the "shared Strings" feature (which is part of the ABI already) to defer the copy from initialisation to if/when the String gets mutated.

Worst case, we can just allocate the memory and copy it in to the String buffer, like the user would have to do themselves, but with better usability because on newer systems it would just be faster.

[johannesweiss]

+1, definitely needed

[jawbroken]

I said, the previous review thread,

@jawbroken

The similar function for Array uses “unsafeUninitializedCapacity” as the argument label, so this proposal should probably match that or explain why the label should be different.

and I guess you chose the former. I'm glad that the label is now consistent and see no other issues here. Thanks for everyone's work on this.

[tkremenek (Ted Kremenek)]

@Karl

This nit remains from the previous version of the proposal:

The new initializer takes a closure that operates on an UnsafeMutableBufferPointer and an inout count of initialized elements.

No it doesn’t.

@David_Smith: was this missed in the update?

[David_Smith]

@tkremenek

inout count of initialized elements.

Looks like it, which is odd because I definitely remember making that edit; I suppose the change must not have saved before I committed. In the interests of expediency, I redid the change and pushed it directly to the s-e repo. The new description is

The new initializer takes a closure that operates on an
UnsafeMutableBufferPointer referencing the uninitialized contents of the newly created
String's storage, and returns a count of initialized elements or 0.

(edit)

Thanks for catching the oversight, @Karl !

[tkremenek (Ted Kremenek)]

Proposal Accepted

This proposal has been accepted with the proposed changes.

Thank you to everyone who participated in the review of SE-0263!