[swift-evolution] [Review] SE-0027 Expose code unit initializers on String

[Marco Masser]

+1

> • What is your evaluation of the proposal?

As the proposal points out, converting Strings to/from their byte representations is common and not at all obvious or easy in Swift at the moment. IMHO, the best solution at the moment is to revert to NSString initializers that take an UnsafePointer<Void>, a length and an encoding.


> • Is the problem being addressed significant enough to warrant a change to Swift?
> • Does this proposal fit well with the feel and direction of Swift?


It’s definitely a good addition to the standard library. Being independent from the NSString Objective-C implementation for basic things is a good idea.


> • If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

It’s a Swifty set of APIs, so I’d say the proposal is fine.
I don’t have a concrete use for the proposed static decode() function that returns whether invalid code units were repaired. But I don’t think there’s much harm in keeping that if some client is interested in it.


> • How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

I was confronted with the exact problem that is being addressed the last couple of days that consisted of the following steps:
• Write a small protocol oriented wrapper around the POSIX socket API that offers methods for sending and receiving Strings.
• Try to convert Strings to/from a collection of UTF8 bytes.
• Read Swift’s standard library source code to see how it’s handled there.
• Revert to NSString bridging.
• Mentally prepare to write proposal to expose these APIs.
• Be delighted that there already is a proposal that is 100% what I wanted.