<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 May 30, 2017, at 14:53, Dave Abrahams <<a href="mailto:dabrahams@apple.com" class="">dabrahams@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class=""><br class="">on Tue May 30 2017, Jordan Rose <jordan_rose-<a href="http://AT-apple.com" class="">AT-apple.com</a>> wrote:<br class=""><br class=""><blockquote type="cite" class="">My knee-jerk reaction is to say it's too late in Swift 4 for this kind<br class="">of change, but with that out of the way, I'm most concerned about what<br class="">it means to have, say, a UTF-8 index that's not on a UTF-16 boundary.<br class=""><br class="">let str = "言"<br class="">let oneUnitIn = str.utf8.index(after: str.utf8.startIndex)<br class="">let trailingBytes = str.utf8[oneUnitIn...]<br class=""></blockquote><br class="">This is not new; it exists today.<br class=""></div></div></blockquote><div><br class=""></div><div>Yes, I think that’s valuable. What’s different is that it’s not a String.Index.</div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><br class=""><blockquote type="cite" class="">What can I do with 'oneUnitIn'? <br class=""></blockquote><br class="">All the usual stuff; we're not proposing to change what you can do with<br class="">it.<br class=""></div></div></blockquote><div><br class=""></div><div>By changing the type, you have increased the scope of where an index <i class="">can</i> be used. What happens when I use it in one of the other views and it’s not on a boundary?</div><div><br class=""></div><div>(I suspect the answer is “it traps” but the proposal should spell that out explicitly.)</div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><br class=""><blockquote type="cite" class="">How do I test to see if it's on a Character boundary or a<br class="">UnicodeScalar boundary?<br class=""></blockquote><br class="">as noted,<br class=""><br class=""> Replacing the failable APIs listed [above](#motivation) that detect<br class=""> whether an index represents a valid position in a given view, and<br class=""> enhancement that explicitly round index positions to nearby boundaries<br class=""> in a given view, are left to a later proposal. For now, we do not<br class=""> propose to remove the existing index conversion APIs.<br class=""><br class="">That means you can use oneUnitIn.samePosition(in: str) or<br class="">oneUnitIn.samePosition(in: str.unicodeScalars) to find out if it's on ta<br class="">character or unicode scalar boundary.</div></div></blockquote><br class=""></div><div>I’m sorry, I completely missed that. This part of the question is withdrawn.</div><div><br class=""></div><div>I’m also concerned about putting “UTF-16” in the documentation for encodedOffset. Either it’s a ‘utf16Offset’ or it isn’t; if it’s an opaque value then it should be treated as such. (It’s also a little disturbing that round-tripping through encodedOffset isn’t guaranteed to give you the same index back.)</div><div><br class=""></div><div>Jordan</div><br class=""></body></html>