[swift-evolution] Pitch: String Index Overhaul

[Jordan Rose]

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 <swift-evolution at swift.org> 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/)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170530/30555bf4/attachment.html>