[swift-evolution] Int indexing into UTF16View

[David Hart]

> 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 <mailto: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 <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <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/2b1a0922/attachment.html>