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