[swift-evolution] Int indexing into UTF16View
Xiaodi Wu
xiaodi.wu at gmail.com
Thu Jun 8 16:11:43 CDT 2017
At some point–although it’s unclear if it’s still the case after the recent
String revisions–it was the case that Foundation extended String to allow
integer subscripting of UTF16View.
The issue with offering it generally is that it doesn’t reliably serve any
use case. You’re using it for performance, which works currently because
the underlying storage is UTF16-encoded, but this is explicitly _not_
guaranteed to remain the case going forward, and then your performance
would be impacted.
If I recall, the core team has said that the only guarantee of the
performance you’re looking for is to store the string yourself as a
sequence of bytes (using Data, for example). The argument is that, in your
barcode example, you’re not really manipulating it as a string at all, but
are relying on its being a particular sequence of bytes. As it happens,
when this topic has come up previously, it has also been the case that the
use case presented treated the string as a known sequence of bytes.
On Thu, Jun 8, 2017 at 16:26 David Hart via swift-evolution <
swift-evolution at swift.org> wrote:
> On 8 Jun 2017, at 12:35, Tony Allevato <tony.allevato at gmail.com> wrote:
>
> It is an extremely rare case for a developer to know a priori what literal
> numeric indices should be used when indexing into a string, because it only
> applies when strings fall into a very specific format and encoding.
>
> It's been discussed before during String-related proposals but AFAIK the
> core team has come out against it—it would be an invitation for users who
> don't understand the distinction to do very unsafe and wrong things with
> strings. IMO, writing your own extension or using index.offset(by:) isn't a
> huge penalty here.
>
>
> Is it really an invitation when it’s hidden inside the UTF16View?
>
> On Thu, Jun 8, 2017 at 10:32 AM David Hart via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>> Hello,
>>
>> When working with Strings which are known to be ASCII, I tend to use the
>> UTF16View for the performance of random access. I would also like to have
>> the convenience of indexing with Int:
>>
>> let barcode = "M1XXXXXXXXX/CLEMENT EELT9QBQGVAAMSEZY1353 244 21D 531
>> 10A1311446838”
>> let name = barcode.utf16[2..<22]
>> let pnrCode = barcode.utf16[23..<30]
>> let seatNo = barcode.utf16[47..<51]
>> let fromCity = barcode.utf16[30..<33]
>> let toCity = barcode.utf16[33..<36]
>> let carrier = barcode.utf16[36..<39]
>> let flightNumber = barcode.utf16[39..<44]
>> let day = barcode.utf16[44..<47]
>>
>> I define my own subscript in an extension to UTF16View but I think this
>> should go in the Standard Library.
>> Any thoughts?
>>
>> David.
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170608/fec15be7/attachment.html>
More information about the swift-evolution
mailing list