<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On 23. Jun 2017, at 02:59, Kevin Ballard via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class="">
<title class=""></title>
<div class=""><blockquote class=""><div class=""><span class="colour" style="color:rgb(119, 119, 119)"><span class="font" style="font-family:-apple-system-body, Helvetica, arial, sans-serif"><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0180-string-index-overhaul.md" style="font-family:'SF Hello';" class="">https://github.com/apple/swift-evolution/blob/master/proposals/0180-string-index-overhaul.md</a></span></span><br class=""></div>
</blockquote><div class=""><br class=""></div>
<div class="">Given the discussion in the original thread about potentially having Strings backed by something other than utf16 code units, I'm somewhat concerned about having this kind of vague `encodedOffset` that happens to be UTF16 code units. If this is supposed to represent an offset into whatever code units the String is backed by, then it's going to be a problem because the user isn't supposed to know or care what the underlying storage for the String is.</div></div></div></blockquote><div><br class=""></div><div>Is that true? The String manifesto shows a design where the underlying Encoding and code-units are exposed.</div><div><br class=""></div><div>From the talk about String’s being backed by something that isn’t UTF-16, I took that to mean that String might one-day become generic. Defaults for generic parameters have been mentioned on the list before, so “String” could still refer to “String<UTF16Encoding>” on OSX and maybe “String<UTF8Encoding>” on Linux.</div><div><br class=""></div><div>I would support a definition of encodedOffset that removed mention of UTF-16 and phrased things in terms of String.Encoding and code-units. For example, I would like to be able to construct new String indices from a known index plus a quantity of code-units known to represent a sequence of characters:</div><div><br class=""></div></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div><div><font face="Menlo" class="">var stringOne = “Hello,“</font></div></div><div><div><font face="Menlo" class="">let stringTwo = “ world"</font></div></div><div><div><font face="Menlo" class=""><br class=""></font></div></div><div><div><font face="Menlo" class="">var idx = stringOne.endIndex</font></div></div><div><div><font face="Menlo" class="">stringOne.append(contentsOf: stringTwo)</font></div></div><div><div><font face="Menlo" class="">idx = String.Index(encodedOffset: idx.encodedOffset + stringTwo.codeUnits.count)</font></div></div><div><div><font face="Menlo" class="">assert(idx == stringOne.endIndex)</font></div></div></blockquote><div><br class=""></div><div>- Karl</div></body></html>