Ok, appending was a dumb example (It has been a long week). Imagine the same idea with insert/remove…
Thanks, Jon > On Feb 10, 2017, at 5:49 PM, Jonathan Hull via swift-evolution > <swift-evolution@swift.org> wrote: > > 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. > > 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. > > 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). > > 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. > > 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: > > func append(_ element:Element, adjusting: [Index]) -> [Index?] > func appending(_ element:Element, adjusting: [Index]) -> (Self, > [Index?]) > > Thanks, > Jon > > >> On Feb 9, 2017, at 3:45 PM, Hooman Mehr via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >> >>> On Feb 9, 2017, at 3:11 PM, Dave Abrahams <dabrah...@apple.com >>> <mailto:dabrah...@apple.com>> wrote: >>> >>> >>> on Thu Feb 09 2017, "Ted F.A. van Gaalen" <tedvgiosdev-AT-gmail.com >>> <http://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. >> >> >>> >>>>> On 9 Feb 2017, at 16:48, Shawn Erickson <shaw...@gmail.com >>>>> <mailto:shaw...@gmail.com>> 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 >>>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org> >>>>> <mailto:swift-evolution@swift.org <mailto:swift-evolution@swift.org>>> >>>>> 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 <hoo...@mac.com >>>>>> <mailto:hoo...@mac.com> <mailto:hoo...@mac.com <mailto:hoo...@mac.com>>> >>>>>> wrote: >>>>>> >>>>>> >>>>>>> On Feb 7, 2017, at 12:19 PM, Ted F.A. van Gaalen via swift-evolution >>>>>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org> >>>>>>> <mailto:swift-evolution@swift.org <mailto:swift-evolution@swift.org>>> >>>>>>> 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 >>>>> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >>>>> <mailto:swift-evolution@swift.org <mailto:swift-evolution@swift.org>> >>>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >>>> <https://lists.swift.org/mailman/listinfo/swift-evolution >>>> <https://lists.swift.org/mailman/listinfo/swift-evolution>> >>>> >>> >>> -- >>> -Dave >> >> _______________________________________________ >> swift-evolution mailing list >> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >> https://lists.swift.org/mailman/listinfo/swift-evolution > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
