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]> 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]> wrote: > > > On Feb 7, 2017, at 12:19 PM, Ted F.A. van Gaalen via swift-evolution < > [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] > https://lists.swift.org/mailman/listinfo/swift-evolution >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
