Reimplementing String Foundation overlay methods

A lot of basic functionality requires the Foundation overlay, such as String.components(separatedBy:). Besides the unfortunate need to bridge the string into Obj-C, any strings created by this are also going to be backed by NSString. This was bad enough before, but now in Swift 5 that native strings are UTF-8 we can expect performance-sensitive code to be optimized more for UTF-8 and thus having UTF-16 strings will be a bigger performance hit.

I'd like to see us consider rewriting some of these Foundation overlay methods in Swift. They can still be part of the overlay, but instead of bridging into the Foundation framework directly, they could just be implemented in pure Swift. components(separatedBy:) would be a great candidate for this.

We can't reimplement everything, obviously. In particular, things that rely on locales would be complicated to rewrite, or things like the enumerate substrings API, or regular expression searching. But the simpler stuff like components(separatedBy:) we absolutely could write ourselves.

I've actually filed this as a bug, since it's purely an implementation detail, I'm just posting this here to get some visibility: SR-10225


If we're excluding locale and interaction with other Foundation types, then all of these should be in the stdlib as discussed in e.g. String Essentials and String Consumption


Moving APIs like this into the stdlib would require a full API design and review process. I'm certainly all for having a stdlib provide all this functionality that we're currently relying on Foundation for, but I expect that to be a long and fairly involved process to come up with the stdlib API we want. In the meantime, we can just produce compatible reimplementations of some of the basic Foundation overlay functionality without taking it out of the overlay and therefore without requiring any sort of API design or review. It would be a stepping stone towards the future of a pure-Swift-stdlib string manipulation story.


Overlay patches that do not change the API surface are welcome, and I'm going to file a bug to track this.