<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=""><div dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Sorry, it looks like I left you hanging on this–luckily I found it when I was cleaning my inbox.<div class=""><br class=""></div><div class="">Overall, I believe the issue I have with the Swift String indexing model is that indices cannot be operated on like an Int can–you can multiply, divide, square, whatever you want on integer indices, while String.Index only allows for what is essentially addition and subtraction. Now, I get that these operations may not make sense on most Strings; the existing API covers them well. However, there are cases, where these operations would be convenient; such as when dealing with fixed-length records or tables of data; almost invariably these are stored as ASCII. Thus, for these cases, I believe that there should be some way to let String know that we are dealing with something that is purely ASCII, so that it can allow us to use these operations in an efficient manner (for example, having an optional .asciiString property that conforms to RandomAccess; since I don’t believe that extendedASCII does). Such an API would keep the existing String paradigm, which is what is needed most of the time, but allowing for random access when the data can be guaranteed to support it.</div><div class=""><br class=""></div><div class="">I’m not sure if I’m getting my point across, please do let me know if you don’t quite get what I mean.</div><div class=""><br class=""><div class="">
<div style="color: rgb(0, 0, 0); letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Saagar Jha</div>

</div>
<br class=""><div><blockquote type="cite" class=""><div class="">On Jan 20, 2017, at 5:55 PM, Ben Cohen &lt;<a href="mailto:ben_cohen@apple.com" class="">ben_cohen@apple.com</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Jan 20, 2017, at 2:58 PM, Saagar Jha via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">Sorry if I wasn’t clear; I’m looking for indexing using Int, instead of using formIndex.</span><br class="Apple-interchange-newline"></div></blockquote></div><div class=""><br class=""></div><div class="">Question: why do you think integer indices are so desirable?</div><div class=""><br class=""></div><div class="">Integer indexing is simple, but also encourages anti-patterns (tortured open-coded while loops with unexpected fencepost errors, conflation of positions and distances into a single type) and our goal should be to make most everyday higher-level operations, such as finding/tokenizing, so easy that Swift programmers don’t feel they need to resort to loops as often.</div><div class=""><br class=""></div><div class="">Examples where formIndex is so common yet so cumbersome that it would be worth efforts to create integer-indexed versions of string might be indicators of important missing features on our collection or string APIs. So do pass them along.</div><div class=""><br class=""></div><div class="">(There are definitely known gaps in them today – slicing needs improving as the manifesto mentions for things like slices from an index to n elements later. Also, we need support for in-place remove(where:) operations. But the more commonly needed cases we know about that aren’t covered, the better)</div><div class=""><br class=""></div><div class=""><br class=""></div></div></div></blockquote></div><br class=""></div></div></body></html>