[swift-dev] String comparison improvements

[Itai Ferber]

Hi Lance (and Michael — I’ll keep the conversation in one thread),

Sounds reasonable. My one concern is that behavior around implicitly 
bridged strings is going to change, in a potentially problematic and 
"magic" way:

```swift
let s1: String = …
let s2: String = …

let mySet = NSMutableSet()
mySet.add(s1)
mySet.add(s2)

// s1 != s2 by Swift ordering rules, but CFStringCompare(s1, s2, …) == 
kCFCompareEqualTo
print(mySet.count) // => 1 ????
```

or alternatively:

```swift
let s1: String = …
let s2: String = …

let mySet = NSMutableSet()
mySet.add(s1)

// s1 == s2 by Swift ordering rules, but CFStringCompare(s1, s2, …) != 
kCFCompareEqualTo
print(mySet.contains(s2)) // => false ????
```

I don’t think there’s much we can do about this, but this is 
something we’re going to have to watch out for — this will be a 
relatively rare and very subtle behavior change.

— Itai

On 17 Jan 2018, at 13:56, Lance Parker wrote:

> Comments inline below
>
>> On Jan 17, 2018, at 1:46 PM, Itai Ferber <iferber at apple.com> wrote:
>>
>> Hi Lance,
>>
>> I read Michael’s emails but I don’t remember at the moment — 
>> what is the new string comparison implementation going to be based 
>> on?
>>
> The new approach uses the lexicographical ordering of NFC-normalized 
> UTF-16 code units. For two known ASCII strings, we just use memcmp.
>> Also, how will this affect bridged strings? If I compare two 
>> NSStrings, I may get a different result than if I compare the same 
>> two strings as bridged through String, correct?
>>
> If I understand correctly, you’re asking what will happen if you 
> have two strings explicitly typed as NSString in swift and you compare 
> them. I believe they’ll still use whatever NSString does for 
> comparison today, so CFStringCompare. For Swift strings backed by a 
> bridged NSString, this new comparison method will be used.
>
> It might make sense for explicit NSStrings in Swift to use the new 
> method as well. What do you think?
>> — Itai
>>
>> On 17 Jan 2018, at 13:19, Lance Parker via swift-dev wrote:
>>
>> Hey Swift-Dev,
>>
>> The swift standard library team  have been working on a new 
>> implementation for comparing Swift strings for Swift 5. Michael 
>> touched on the motivations in the State of String email but I’ll 
>> summarize here:
>>
>> The Swift String comparison implementations on Apple platforms and 
>> Linux differ in results and performance. Apple platforms use 
>> CFStringCompare with no locale, while Linux uses ICU libraries. 
>> Unifying the algorithms that Swift strings use for comparison is 
>> reason alone for doing a new implementation.
>> We've come up with some great common fast paths that speed up 
>> comparisons for a lot of common cases. Our microbenchmarks show up to 
>> a 6.8x increase in performance and there is still some low hanging 
>> fruit in our implementation that would bring further speedups.
>>
>> Bare in mind this is not intended to be a replacement for sorting 
>> strings that will be presented to users, for that developers should 
>> stick to NSLocalizedString APIs.
>> _______________________________________________
>> swift-dev mailing list
>> swift-dev at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-dev 
>> <https://lists.swift.org/mailman/listinfo/swift-dev>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-dev/attachments/20180117/2eff6e0f/attachment.html>