[swift-evolution] Strings in Swift 4

[Shawn Erickson]

On Thu, Feb 9, 2017 at 3:45 PM Hooman Mehr <hooman at mac.com> wrote:

> On Feb 9, 2017, at 3:11 PM, Dave Abrahams <dabrahams at apple.com> wrote:
>
>
> on Thu Feb 09 2017, "Ted F.A. van Gaalen" <tedvgiosdev-AT-gmail.com>
> wrote:
>
> Hello Shawn
> Just google with any programming language name and “string manipulation”
> and you have enough reading for a week or so :o)
> TedvG
>
>
> That truly doesn't answer the question.  It's not, “why do people index
> strings with integers when that's the only tool they are given for
> decomposing strings?”  It's, “what do you have to do with strings that's
> hard in Swift *because* you can't index them with integers?”
>
>
> 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.
>
> 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 *integer*, 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.
>

 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?

-Shawn
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170210/ea444d1b/attachment.html>