[swift-evolution] [Review] SE-0180: String Index Overhaul

[Kevin Ballard]

https://github.com/apple/swift-evolution/blob/master/proposals/0180-string-index-overhaul.md <https://github.com/apple/swift-evolution/blob/master/proposals/0180-string-index-overhaul.md>

Overall it looks pretty good. But unfortunately the answer to "Will applications still compile but produce different behavior than they used to?" is actually "Yes", when using APIs provided by Foundation. This is because Foundation is currently able to return String.Index values that don't point to Character boundaries.

Specifically, in Swift 3, the following code:

import Foundation

let str = "e\u{301}galite\u{301}"
let r = str.rangeOfCharacter(from: ["\u{301}"])!
print(str[r] == "\u{301}")

will print “true”, because the returned range identifies the combining acute accent only. But with the proposed String.Index revisions, the `str[r]` subscript will return the whole "e\u{301}” combined character.

This is, of course, an edge case, but we need to consider the implications of this and determine if it actually affects anything that’s likely to be a problem in practice.

There’s also the curious case where I can have two String.Index values that compare unequal but actually return the same value when used in a subscript. For example, with the above string, if I have a String.Index(encodedOffset: 0) and a String.Index(encodedOffset: 1). This may not be a problem in practice, but it’s something to be aware of.

I’m also confused by the paragraph about index comparison. It talks about if two indices are valid in a single String view, comparison semantics are according to Collection, and otherwise indexes are compared using encodedOffsets, and this means indexes aren’t totally ordered. But I’m not sure what the first part is supposed to mean. How is comparing indices that are valid within a single view any different than comparing the encodedOffsets?

-Kevin Ballard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170605/08599fff/attachment.html>