<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=""><br class=""><div><blockquote type="cite" class=""><div class="">On Feb 10, 2017, at 12:38 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 6:50 PM, Shawn Erickson <<a href="mailto:shawnce@gmail.com" class="">shawnce@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; 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;" class=""><br class=""><br class=""><div class="gmail_quote"><div dir="ltr" class="">On Thu, Feb 9, 2017 at 3:45 PM Hooman Mehr <<a href="mailto:hooman@mac.com" class="">hooman@mac.com</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;"><div class="gmail_msg" style="word-wrap: break-word;"><div class="gmail_msg"><div class="gmail_msg"><blockquote type="cite" class="gmail_msg"><div class="gmail_msg">On Feb 9, 2017, at 3:11 PM, Dave Abrahams <<a href="mailto:dabrahams@apple.com" class="gmail_msg" target="_blank">dabrahams@apple.com</a>> wrote:</div><br class="m_-2261049595563293574Apple-interchange-newline gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><br class="gmail_msg">on Thu Feb 09 2017, "Ted F.A. van Gaalen" <<a href="http://tedvgiosdev-at-gmail.com/" class="gmail_msg" target="_blank">tedvgiosdev-AT-gmail.com</a>> wrote:<br class="gmail_msg"><br class="gmail_msg"><blockquote type="cite" class="gmail_msg">Hello Shawn<br class="gmail_msg">Just google with any programming language name and “string manipulation”<br class="gmail_msg">and you have enough reading for a week or so :o)<br class="gmail_msg">TedvG<br class="gmail_msg"></blockquote><br class="gmail_msg">That truly doesn't answer the question. It's not, “why do people index<br class="gmail_msg">strings with integers when that's the only tool they are given for<br class="gmail_msg">decomposing strings?” It's, “what do you have to do with strings that's<br class="gmail_msg">hard in Swift *because* you can't index them with integers?”<br class="gmail_msg"></div></div></blockquote><div class="gmail_msg"><br class="gmail_msg"></div></div></div></div><div class="gmail_msg" style="word-wrap: break-word;"><div class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg">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="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">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<span class="Apple-converted-space"> </span><b class="gmail_msg">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></div></div></blockquote><div class=""><br class=""></div><div class=""> The end goal of this string is for human consumption right? So such manipulation would need need to unicode aware in the modern world? ..or is it for some other reason?</div><div class=""><br class=""></div><div class="">-Shawn</div></div></div></div></blockquote></div><br class=""></div><div class="">For an example of what I mean, see the source code of <a href="https://github.com/apple/swift-corelibs-foundation/blob/master/Foundation/NSAttributedString.swift" class="">NS(Mutable)AttributedString</a> and note how most of the mutating methods of Mutable variant are not implemented yet...</div><div class=""><br class=""></div><div class="">So, a good example of where such indexing would be convenient, could be writing a swift-native AttributedString backed by Swift native String.</div></div></div></blockquote></div><br class=""><div class="">On that last topic, NSAttributedString has always seemed like a strange design — a class with a bunch of attribute methods with a property that lets you interrogate the String behind it all. </div><div class=""><br class=""></div><div class="">It always seemed to me that there was a false distinction. Strings should have optional properties, the way GameplayKit does GKEntities and GKComponents.</div><div class=""><br class=""></div><div class="">Simple Strings would return nil if you asked them for their attributes.</div><div class=""><br class=""></div><div class="">Attributed Strings would return attributes.</div><div class=""><br class=""></div><div class="">I think it would be a lot more intuitive how to parse an attributed string in blocks and then refer back to the attributes of each chunk, for one thing.</div><div class=""><br class=""></div><div class="">Is there a reason why composition was chosen to be the way it is in NSAttributedString, instead?</div><div class=""><br class=""></div><div class="">- Ron</div></body></html>