My knee-jerk reaction is to say it's too late in Swift 4 for this kind of change, but with that out of the way, I'm most concerned about what it means to have, say, a UTF-8 index that's not on a UTF-16 boundary.
let str = "言" let oneUnitIn = str.utf8.index(after: str.utf8.startIndex) let trailingBytes = str.utf8[oneUnitIn...] What can I do with 'oneUnitIn'? How do I test to see if it's on a Character boundary or a UnicodeScalar boundary? Jordan > On May 27, 2017, at 10:40, Dave Abrahams via swift-evolution > <[email protected]> wrote: > > > Pretty version: > https://github.com/dabrahams/swift-evolution/blob/string-index-overhaul/proposals/NNNN-string-index-overhaul.md > > ---- > > # String Index Overhaul > > * Proposal: [SE-NNNN](NNNN-string-index-overhaul.md) > * Authors: [Dave Abrahams](https://github.com/dabrahams) > * Review Manager: TBD > * Status: **Awaiting review** > * Pull Request Implementing This Proposal: > https://github.com/apple/swift/pull/9806 > > *During the review process, add the following fields as needed:* > > ## Introduction > > Today `String` shares an `Index` type with its `CharacterView` but not > with its `UTF8View`, `UTF16View`, or `UnicodeScalarView`. This > proposal redefines `String.UTF8View.Index`, `String.UTF16View.Index`, > and `String.CharacterView.Index` as typealiases for `String.Index`, > and exposes a public `encodedOffset` property and initializer that can > be used to serialize and deserialize positions in a `String` or > `Substring`. > > Swift-evolution thread: [Discussion thread topic for that > proposal](https://lists.swift.org/pipermail/swift-evolution/)
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
