<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div><br></div><div>On 8 Jun 2017, at 14:11, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com">xiaodi.wu@gmail.com</a>> wrote:<br><br></div><blockquote type="cite"><div>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.<br><br>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.<br><br>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.<br></div></blockquote><div><br></div><div>I understand what you are saying. It's just a pitty that it's making the code much more complicated than it should be.</div><br><blockquote type="cite"><div><div class="gmail_quote"><div dir="ltr">On Thu, Jun 8, 2017 at 16:26 David Hart via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><blockquote type="cite"><div>On 8 Jun 2017, at 12:35, Tony Allevato <<a href="mailto:tony.allevato@gmail.com" target="_blank">tony.allevato@gmail.com</a>> wrote:</div><br class="m_4707905404176416221Apple-interchange-newline"><div><div dir="ltr">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.<div><br></div><div>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.</div></div></div></blockquote><div><br></div></div></div><div style="word-wrap:break-word"><div><div>Is it really an invitation when it’s hidden inside the UTF16View?</div></div></div><div style="word-wrap:break-word"><div><br><blockquote type="cite"><div><div class="gmail_quote"><div dir="ltr">On Thu, Jun 8, 2017 at 10:32 AM David Hart via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello,<br>
<br>
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:<br>
<br>
let barcode = "M1XXXXXXXXX/CLEMENT EELT9QBQGVAAMSEZY1353 244 21D 531 10A1311446838”<br>
let name = barcode.utf16[2..<22]<br>
let pnrCode = barcode.utf16[23..<30]<br>
let seatNo = barcode.utf16[47..<51]<br>
let fromCity = barcode.utf16[30..<33]<br>
let toCity = barcode.utf16[33..<36]<br>
let carrier = barcode.utf16[36..<39]<br>
let flightNumber = barcode.utf16[39..<44]<br>
let day = barcode.utf16[44..<47]<br>
<br>
I define my own subscript in an extension to UTF16View but I think this should go in the Standard Library.<br>
Any thoughts?<br>
<br>
David.<br>
_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</blockquote></div>
</div></blockquote></div></div>_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</blockquote></div>
</div></blockquote></body></html>