<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"><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 7, 2017, at 1:19 PM, Ted F.A. van Gaalen <<a href="mailto:tedvgiosdev@gmail.com" class="">tedvgiosdev@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class=""><div class=""><blockquote type="cite" class="" 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-size-adjust: auto; -webkit-text-stroke-width: 0px;"><div class=""><div class=""><br class="">That proves nothing, though. The fact that people are using integers to<br class="">do this doesn't mean you need to use them, nor does it mean that you'll<br class="">get the right results from doing so. Typically examples that use<br class="">integer constants with strings are wrong for some large proportion of<br class="">unicode text.<br class=""><br class=""></div></div></blockquote><span 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; float: none; display: inline !important;" class=""> This is all a bit confusing. </span></div><div class="">in <a href="https://en.wiktionary.org/wiki/glyph" class="">https://en.wiktionary.org/wiki/glyph</a><br class=""> Definition of a glyph in our context: <br class=""><ol class="" style="margin: 0.3em 0px 0px 3.2em; padding: 0px; list-style-image: none; color: rgb(37, 37, 37); font-family: sans-serif;"><li class="" style="margin-bottom: 0.1em; page-break-inside: avoid; break-inside: avoid; -webkit-column-break-inside: avoid;"><span class="ib-brac">(</span><span class="ib-content" style="font-style: italic;">typography<span class="ib-comma" style="font-style: normal;">,</span> computing</span><span class="ib-brac">)</span> A visual representation of a <a href="https://en.wiktionary.org/wiki/letter" title="letter" class="" style="text-decoration: none; color: rgb(11, 0, 128); background-image: none;">letter</a>, <a href="https://en.wiktionary.org/wiki/character" title="character" class="" style="text-decoration: none; color: rgb(11, 0, 128); background-image: none;">character</a>, or <a href="https://en.wiktionary.org/wiki/symbol" title="symbol" class="" style="text-decoration: none; color: rgb(11, 0, 128); background-image: none;">symbol</a>, in a specific <a href="https://en.wiktionary.org/wiki/font" title="font" class="" style="text-decoration: none; color: rgb(11, 0, 128); background-image: none;">font</a> and <a href="https://en.wiktionary.org/wiki/style" title="style" class="" style="text-decoration: none; color: rgb(11, 0, 128); background-image: none;">style</a>.</li></ol><div class=""><font color="#252525" face="sans-serif" class=""><br class=""></font></div><div class=""><font color="#252525" face="sans-serif" class="">I now assume that:</font></div><div class=""><font color="#252525" face="sans-serif" class=""> 1. -= a “plain” Unicode character (codepoint?) can result in one glyph.=-</font></div><div class=""><font color="#252525" face="sans-serif" class=""> 2. -= a grapheme cluster always results in just a single glyph, true? =- </font></div><div class=""><font color="#252525" face="sans-serif" class=""> 3. The only thing that I can see on screen or print are glyphs (“carvings”,visual elements that stand on their own )</font></div><div class=""><font color="#252525" face="sans-serif" class=""> 4. In this context, a glyph is a humanly recognisable visual form of a character,</font></div><div class=""><span class="" style="color: rgb(37, 37, 37); font-family: sans-serif;"> 5. On this level (the glyph, what I can see as a user) it is not relevant and also not detectable</span></div><div class=""><span class="" style="color: rgb(37, 37, 37); font-family: sans-serif;"> with how many Unicode scalars (codepoints ?), grapheme, or even on what kind</span></div><div class=""><span class="" style="color: rgb(37, 37, 37); font-family: sans-serif;"> of encoding the glyph was based upon.</span></div><div class=""><span class="" style="color: rgb(37, 37, 37); font-family: sans-serif;"><br class=""></span></div><div class=""><font color="#252525" face="sans-serif" class=""> is this correct? (especially 1 and 2) </font></div><div class=""><font color="#252525" face="sans-serif" class=""><br class=""></font></div><div class=""><font color="#252525" face="sans-serif" class="">Based on these assumptions, to me then, the definition of a character == glyph.</font></div><div class=""><span class="" style="color: rgb(37, 37, 37); font-family: sans-serif;">Therefore, my working model: I see a row of characters as a row of glyphs,</span></div><div class=""><span class="" style="color: rgb(37, 37, 37); font-family: sans-serif;">which are discrete autonomous visual elements, ergo: </span></div><div class=""><font color="#252525" face="sans-serif" class="">Each element is individually addressable with integers (ordinal)</font></div><div class=""></div></div></div></div></div></blockquote><div><br class=""></div>While this is true, the encoding(s) have focused on memory size, operational performance, and compatibility with existing tools over the ability to perform integer-indexed random access. Even a Character in Swift that would be returned via random access is effectively a substring, due to the value being of arbitrary size.</div><div><br class=""></div><div>In my experience, many languages and thus many developers use strings both as text and as data. This is even more common in scripting languages, where you don’t have nil-termination to contend with for storing binary data within a ‘string’.</div><div><br class=""></div><div>I assume Swift has taken the standpoint that text cannot be handled properly or safely unless it is considered distinct from data, and thus the need for random access goes down significantly when String is being used properly.</div><div><br class=""></div><div>Perhaps it would help if you provide a real world example where String requires random access?</div><div><br class=""></div><div>-DW</div><br class=""></body></html>