やっと読めた。

8:12 AM

https://forums.swift.org/t/se-0241-explicit-encoded-offsets-for-string-indices/19929/36

SE-0241: Explicit Encoded Offsets for String Indices

The original proposal sought to solve 3 problems: SE-0180’s encodedOffset, meant for serialization purposes, needs to be parameterized over the encoding in which the string will be serialized in Existing uses of encodedOffset need a semantics-preserving off-ramp for Swift...

8:14 AM

コアチーム的に新しい事をSwift5.0に追加するにはおそすぎるけど、内部がUTF-8になる事によって、元々のUTF-16のつもりでやってたやつを移行する(semantics-preserving)APIだけは緊急に必要で(urgent fixes)

8:16 AM

という話か。一つ前の>>35でも興味深い指摘がされてますね。

8:17 AM

元々正しい書き換えして出ていた、 string.utf16.index(string.startIndex, by: offset) という書き方だと (edited)

8:17 AM

もともとは String.Index(encodedOffset: offset) でパラメータがoffsetだけだったのに対して

8:17 AM

対象のstringが必要になっちゃってる

8:18 AM

で、NSString系のNSRangeが返ってくる系のコールバックだと

8:18 AM

 func processEdit(editedNSRange: NSRange, changeInLenght delta: Int) { let editedRange = Range<String.Index>(uncheckedBounds: ( String.Index(encodedOffset: editedNSRange.lowerBound), String.Index(encodedOffset: editedNSRange.upperBound) )) ...

8:18 AM

こういうふうに元々stringなしでNSRangeからRange<String.Index>に持っていけてたから

8:19 AM

この用途をカバーするAPIが必要なんですね。

8:20 AM

あれ？修正提案でも public init<S: StringProtocol>(utf16Offset offset: Int, in s: S) { こうなってるな。