[swift-evolution] Strings in Swift 4

[Ben Cohen]

> On Jan 25, 2017, at 1:39 PM, Zach Waldowski <zach at waldowski.me> wrote:
> 
> The ultimate model of strings is going to be complicated whether or not it’s on String itself, although I argue that regardless of that complexity, Swift inherently starts from a much better place than f.ex. Java from just having Array vs. 30 different Array-like things. That dovetails into the point I was trying to make up-thread, which is that complicating the overall type space to serve specific use cases practically results in less-experienced users not knowing about or not finding it, even when they need to. Furthermore, “use UTF8String when you need to to be super-fast (and don’t we all want to be super fast???)” is the kind of cargo-culting that sticks, not “when caveats A, B, C, and D apply and you want to be fast and you’ve considered all the Unicode implications and when the optimizer breaks down and you have observed a performance problem you should consider etc etc etc”.
> 

I’m normally all in favor of the “don’t give people features, or they'll use them too much” argument but in this case I don’t think it applies.

We even have a case study to look at already, very similar to this one. Unfortunately we do have more than one Array-like thing – ContiguousArray. It’s there for avoiding performance problems caused by the consequences of Objective-C bridging, and the documentation describes the fairly specific circumstances when you might use when it “may be more efficient and have more predictable performance than Array.” This hasn’t led to people cargo cutting the use of ContiguousArray in places where it would be inappropriate, as far as I can tell.