<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="Content-Type" content="text/xhtml; charset=utf-8">
</head>
<body>
<div style="font-family:sans-serif"><div style="white-space:normal">
<p dir="auto">Hi Lance (and Michael — I’ll keep the conversation in one thread),</p>
<p dir="auto">Sounds reasonable. My one concern is that behavior around implicitly bridged strings is going to change, in a potentially problematic and "magic" way:</p>
<pre style="background-color:#F7F7F7; border-radius:5px 5px 5px 5px; margin-left:15px; margin-right:15px; max-width:90vw; overflow-x:auto; padding:5px; color:black" bgcolor="#F7F7F7"><code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0" bgcolor="#F7F7F7"><span style="color: #008800; font-weight: bold">let</span> <span style="color: #996633">s1</span>: <span style="color: #007020">String</span> = <span style="color: #FF0000; background-color: #FFAAAA">…</span>
<span style="color: #008800; font-weight: bold">let</span> <span style="color: #996633">s2</span>: <span style="color: #007020">String</span> = <span style="color: #FF0000; background-color: #FFAAAA">…</span>
<span style="color: #008800; font-weight: bold">let</span> <span style="color: #996633">mySet</span> = <span style="color: #007020">NSMutableSet</span>()
mySet.add(s1)
mySet.add(s2)
<span style="color: #888888">// s1 != s2 by Swift ordering rules, but CFStringCompare(s1, s2, …) == kCFCompareEqualTo</span>
<span style="color: #007020">print</span>(mySet.<span style="color: #007020">count</span>) <span style="color: #888888">// => 1 ????</span>
</code></pre>
<p dir="auto">or alternatively:</p>
<pre style="background-color:#F7F7F7; border-radius:5px 5px 5px 5px; margin-left:15px; margin-right:15px; max-width:90vw; overflow-x:auto; padding:5px; color:black" bgcolor="#F7F7F7"><code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0" bgcolor="#F7F7F7"><span style="color: #008800; font-weight: bold">let</span> <span style="color: #996633">s1</span>: <span style="color: #007020">String</span> = <span style="color: #FF0000; background-color: #FFAAAA">…</span>
<span style="color: #008800; font-weight: bold">let</span> <span style="color: #996633">s2</span>: <span style="color: #007020">String</span> = <span style="color: #FF0000; background-color: #FFAAAA">…</span>
<span style="color: #008800; font-weight: bold">let</span> <span style="color: #996633">mySet</span> = <span style="color: #007020">NSMutableSet</span>()
mySet.add(s1)
<span style="color: #888888">// s1 == s2 by Swift ordering rules, but CFStringCompare(s1, s2, …) != kCFCompareEqualTo</span>
<span style="color: #007020">print</span>(mySet.<span style="color: #007020">contains</span>(s2)) <span style="color: #888888">// => false ????</span>
</code></pre>
<p dir="auto">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.</p>
<p dir="auto">— Itai</p>
<p dir="auto">On 17 Jan 2018, at 13:56, Lance Parker wrote:</p>
</div>
<div style="white-space:normal"></div>
<blockquote style="border-left:2px solid #777; color:#777; margin:0 0 5px; padding-left:5px"><div id="69AA7FEA-4C0E-48BC-B1E4-8AC3D10E5656"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Comments inline below<br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Jan 17, 2018, at 1:46 PM, Itai Ferber <<a href="mailto:iferber@apple.com" class="">iferber@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class="">
<meta http-equiv="Content-Type" content="text/xhtml; charset=utf-8" class="">
<div class="">
<div style="font-family:sans-serif" class=""><div style="white-space:normal" class=""><p dir="auto" class="">Hi Lance,</p><p dir="auto" class="">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?<br class=""></p></div></div></div></div></blockquote><div>The new approach uses the lexicographical ordering of NFC-normalized UTF-16 code units. For two known ASCII strings, we just use memcmp.</div><blockquote type="cite" class=""><div class=""><div class=""><div style="font-family:sans-serif" class=""><div style="white-space:normal" class=""><p dir="auto" class="">
Also, how will this affect bridged strings? If I compare two <code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7" class="">NSString</code>s, I may get a different result than if I compare the same two strings as bridged through <code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7" class="">String</code>, correct?</p></div></div></div></div></blockquote>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. </div><div><br class=""></div><div>It might make sense for explicit NSStrings in Swift to use the new method as well. What do you think?</div><div><blockquote type="cite" class=""><div class=""><div class=""><div style="font-family:sans-serif" class=""><div style="white-space:normal" class=""><p dir="auto" class="">— Itai</p><p dir="auto" class="">On 17 Jan 2018, at 13:19, Lance Parker via swift-dev wrote:</p>
</div>
<div style="white-space:normal" class=""></div>
<blockquote style="border-left:2px solid #777; color:#777; margin:0 0 5px; padding-left:5px" class=""><div id="214A73A3-DA3F-4542-B204-52078D232B28" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Hey Swift-Dev,<div class=""><br class=""></div><div class="">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:</div><div class=""><br class=""></div><div class=""><ul class="MailOutline"><li class="">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. </li><li class="">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. </li></ul></div><div class=""><br class=""></div><div class="">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. </div></div></div></blockquote>
<div style="white-space:normal" class="">
<blockquote style="border-left:2px solid #777; color:#777; margin:0 0 5px; padding-left:5px" class="">
</blockquote><blockquote style="border-left:2px solid #777; color:#777; margin:0 0 5px; padding-left:5px" class=""><p dir="auto" class="">_______________________________________________<br class="">
swift-dev mailing list<br class="">
<a href="mailto:swift-dev@swift.org" class="">swift-dev@swift.org</a><br class="">
<a href="https://lists.swift.org/mailman/listinfo/swift-dev" style="color:#777" class="">https://lists.swift.org/mailman/listinfo/swift-dev</a></p>
</blockquote></div>
<div style="white-space:normal" class="">
</div>
</div>
</div>
</div></blockquote></div><br class=""></div></div></blockquote>
<div style="white-space:normal">
<blockquote style="border-left:2px solid #777; color:#777; margin:0 0 5px; padding-left:5px">
</blockquote></div>
<div style="white-space:normal">
</div>
</div>
</body>
</html>