<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="">This is the biggest need I have from strings (and collections) that is not being met, and is I think why people reach for integers. I have a stored index which points to something important, and if the string/collection is edited, I now have to update the index to be correct. Lots of chances to screw up (e.g. off by 1 errors) if I am not super careful.<div class=""><br class=""></div><div class="">I would much rather have that dealt with by the string/collection itself, so that I can think about my larger project instead of keeping everything in sync.</div><div class=""><br class=""></div><div class="">My preferred design for this would be to have two types of index. An internal index (what we have now) which is fast, efficient and transient, and a stable index which will always point to the same item despite having added or removed other items (or be testably invalid if the item pointed to has been removed). For strings, this means the stable index would point to the same characters even if the string has been edited (as long as those characters are still there).</div><div class=""><br class=""></div><div class="">I know the second isn’t useful for algorithms in the standard library, but it is sooooo useful for things like storing user selections… and it is very easy to foot-gun when trying to do it yourself. Keeping stored indexes in sync is among my top annoyances while programming.</div><div class=""><br class=""></div><div class="">An easier to implement, but slightly less useful approach, would be to have methods which take an array of indexes along with the proposed change, and then it adjusts the indexes (or replaces them with nil if they are invalid) as it makes the update. For example:</div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>func append(_ element:Element, adjusting: [Index]) -> [Index?]</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>func appending(_ element:Element, adjusting: [Index]) -> (Self, [Index?])</div><div class=""><br class=""></div><div class="">Thanks,</div><div class="">Jon</div><div class=""><div class=""><div class=""><div class=""><br class=""></div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Feb 9, 2017, at 3:45 PM, Hooman Mehr via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> 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=""><div class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Feb 9, 2017, at 3:11 PM, Dave Abrahams <<a href="mailto:dabrahams@apple.com" class="">dabrahams@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class=""><br class="">on Thu Feb 09 2017, "Ted F.A. van Gaalen" <<a href="http://tedvgiosdev-at-gmail.com/" class="">tedvgiosdev-AT-gmail.com</a>> wrote:<br class=""><br class=""><blockquote type="cite" class="">Hello Shawn<br class="">Just google with any programming language name and “string manipulation”<br class="">and you have enough reading for a week or so :o)<br class="">TedvG<br class=""></blockquote><br class="">That truly doesn't answer the question. It's not, “why do people index<br class="">strings with integers when that's the only tool they are given for<br class="">decomposing strings?” It's, “what do you have to do with strings that's<br class="">hard in Swift *because* you can't index them with integers?”<br class=""></div></div></blockquote><div class=""><br class=""></div><div class="">I have done some string processing. I have not encountered any algorithm where an integer index is absolutely needed, but sometimes it might be the most convenient. </div><div class=""><br class=""></div><div class="">For example, there are valid reasons to keep side tables that hold indexes into a string. (such as maintaining attributes that apply to a substring or things like pre-computed positions of soft line breaks). It does not require the index to be <b class="">integer</b>, but maintaining validity of those indexes after the string is mutated requires being able to offset them back or forth from some position on. These operations could be less verbose and easier if the index happens to be integer or (efficiently) supports + - operators. Also, I know there are other methods to deal with such things and mutating a large string generally is a bad idea, but sometimes it is the easiest and most convenient solution to the problem at hand.</div><div class=""><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><br class=""><blockquote type="cite" class=""><blockquote type="cite" class="">On 9 Feb 2017, at 16:48, Shawn Erickson <<a href="mailto:shawnce@gmail.com" class="">shawnce@gmail.com</a>> wrote:<br class=""><br class="">I also wonder what folks are actually doing that require indexing<br class="">into strings. I would love to see some real world examples of what<br class="">and why indexing into a string is needed. Who is the end consumer of<br class="">that string, etc.<br class=""><br class="">Do folks have so examples?<br class=""><br class="">-Shawn<br class=""><br class="">On Thu, Feb 9, 2017 at 6:56 AM Ted F.A. van Gaalen via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a> <<a href="mailto:swift-evolution@swift.org" class="">mailto:swift-evolution@swift.org</a>>> wrote:<br class="">Hello Hooman<br class="">That invalidates my assumptions, thanks for evaluating<br class="">it's more complex than I thought.<br class="">Kind Regards<br class="">Ted<br class=""><br class=""><blockquote type="cite" class="">On 8 Feb 2017, at 00:07, Hooman Mehr <<a href="mailto:hooman@mac.com" class="">hooman@mac.com</a> <<a href="mailto:hooman@mac.com" class="">mailto:hooman@mac.com</a>>> wrote:<br class=""><br class=""><br class=""><blockquote type="cite" class="">On Feb 7, 2017, at 12:19 PM, Ted F.A. van Gaalen via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a> <<a href="mailto:swift-evolution@swift.org" class="">mailto:swift-evolution@swift.org</a>>> wrote:<br class=""><br class="">I now assume that:<br class=""> 1. -= a “plain” Unicode character (codepoint?) can result in one glyph.=-<br class=""></blockquote><br class="">What do you mean by “plain”? Characters in some Unicode scripts are<br class="">by no means “plain”. They can affect (and be affected by) the<br class="">characters around them, they can cause glyphs around them to<br class="">rearrange or combine (like ligatures) or their visual<br class="">representation (glyph) may float in the same space as an adjacent<br class="">glyph (and seem to be part of the “host” glyph), etc. So, the<br class="">general relationship of a character and its corresponding glyph (if<br class="">there is one) is complex and depends on context and surroundings<br class="">characters.<br class=""><br class=""><blockquote type="cite" class=""> 2. -= a grapheme cluster always results in just a single glyph, true? =- <br class=""></blockquote><br class="">False<br class=""><br class=""><blockquote type="cite" class=""> 3. The only thing that I can see on screen or print are glyphs (“carvings”,visual elements that stand on their own )<br class=""></blockquote><br class="">The visible effect might not be a visual shape. It may be for example, the way the surrounding shapes change or re-arrange.<br class=""><br class=""><blockquote type="cite" class=""> 4. In this context, a glyph is a humanly recognisable visual form of a character,<br class=""></blockquote><br class="">Not in a straightforward one to one fashion, not even in Latin / Roman script.<br class=""><br class=""><blockquote type="cite" class=""> 5. On this level (the glyph, what I can see as a user) it is not relevant and also not detectable<br class=""> with how many Unicode scalars (codepoints ?), grapheme, or even on what kind<br class=""> of encoding the glyph was based upon.<br class=""></blockquote><br class="">False<br class=""><br class=""></blockquote><br class="">_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a> <<a href="mailto:swift-evolution@swift.org" class="">mailto:swift-evolution@swift.org</a>><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></blockquote><<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a>><br class=""><br class=""></blockquote><br class="">-- <br class="">-Dave<br class=""></div></div></blockquote></div><br class=""></div></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></div></div></div></div></body></html>