> On Jan 17, 2018, at 2:36 PM, Itai Ferber wrote:
>
> 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:
>
> let s1: St
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()
> On Jan 17, 2018, at 1:46 PM, Itai Ferber via swift-dev
> 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?
>
It is the lexicographical ordering of NFC-normalized UTF-16 code units.
Comments inline below
> On Jan 17, 2018, at 1:46 PM, Itai Ferber 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-normalize
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?
Also, how will this affect bridged strings? If I compare two
`NSString`s, I may get a different result than if I compare the same two
strings as bridged
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 di
