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 <ifer...@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev
<https://lists.swift.org/mailman/listinfo/swift-dev>
_______________________________________________
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev
