Sent from my moss-covered three-handled family gradunza
> On Feb 9, 2017, at 3:45 PM, Hooman Mehr <[email protected]> wrote: > > >> On Feb 9, 2017, at 3:11 PM, Dave Abrahams <[email protected]> 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. As noted in the manifesto, it will be trivial to translate string indices to/from integer code unit offsets, most likely by a property / an init String indices as proposed will not however support +/- > >> >>>> On 9 Feb 2017, at 16:48, Shawn Erickson <[email protected]> wrote: >>>> >>>> I also wonder what folks are actually doing that require indexing >>>> into strings. I would love to see some real world examples of what >>>> and why indexing into a string is needed. Who is the end consumer of >>>> that string, etc. >>>> >>>> Do folks have so examples? >>>> >>>> -Shawn >>>> >>>> On Thu, Feb 9, 2017 at 6:56 AM Ted F.A. van Gaalen via swift-evolution >>>> <[email protected] <mailto:[email protected]>> wrote: >>>> Hello Hooman >>>> That invalidates my assumptions, thanks for evaluating >>>> it's more complex than I thought. >>>> Kind Regards >>>> Ted >>>> >>>>>> On 8 Feb 2017, at 00:07, Hooman Mehr <[email protected] >>>>>> <mailto:[email protected]>> wrote: >>>>>> >>>>>> >>>>>> On Feb 7, 2017, at 12:19 PM, Ted F.A. van Gaalen via swift-evolution >>>>>> <[email protected] <mailto:[email protected]>> wrote: >>>>>> >>>>>> I now assume that: >>>>>> 1. -= a “plain” Unicode character (codepoint?) can result in one >>>>>> glyph.=- >>>>> >>>>> What do you mean by “plain”? Characters in some Unicode scripts are >>>>> by no means “plain”. They can affect (and be affected by) the >>>>> characters around them, they can cause glyphs around them to >>>>> rearrange or combine (like ligatures) or their visual >>>>> representation (glyph) may float in the same space as an adjacent >>>>> glyph (and seem to be part of the “host” glyph), etc. So, the >>>>> general relationship of a character and its corresponding glyph (if >>>>> there is one) is complex and depends on context and surroundings >>>>> characters. >>>>> >>>>>> 2. -= a grapheme cluster always results in just a single glyph, >>>>>> true? =- >>>>> >>>>> False >>>>> >>>>>> 3. The only thing that I can see on screen or print are glyphs >>>>>> (“carvings”,visual elements that stand on their own ) >>>>> >>>>> The visible effect might not be a visual shape. It may be for example, >>>>> the way the surrounding shapes change or re-arrange. >>>>> >>>>>> 4. In this context, a glyph is a humanly recognisable visual form >>>>>> of a character, >>>>> >>>>> Not in a straightforward one to one fashion, not even in Latin / Roman >>>>> script. >>>>> >>>>>> 5. On this level (the glyph, what I can see as a user) it is not >>>>>> relevant and also not detectable >>>>>> with how many Unicode scalars (codepoints ?), grapheme, or even >>>>>> on what kind >>>>>> of encoding the glyph was based upon. >>>>> >>>>> False >>>>> >>>> >>>> _______________________________________________ >>>> swift-evolution mailing list >>>> [email protected] <mailto:[email protected]> >>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >>> >> >> -- >> -Dave >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
