<html><head><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 10 Feb 2017, at 00:11, Dave Abrahams <<a href="mailto:dabrahams@apple.com" class="">dabrahams@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class=""><br class="">on Thu Feb 09 2017, "Ted F.A. van Gaalen" <<a href="http://tedvgiosdev-AT-gmail.com" class="">tedvgiosdev-AT-gmail.com</a>> wrote:<br class=""><br class=""><blockquote type="cite" class="">Hello Shawn<br class="">Just google with any programming language name and “string manipulation”<br class="">and you have enough reading for a week or so :o)<br class="">TedvG<br class=""></blockquote><br class="">That truly doesn't answer the question. It's not, “why do people index<br class="">strings with integers when that's the only tool they are given for<br class="">decomposing strings?” It's, “what do you have to do with strings that's<br class="">hard in Swift *because* you can't index them with integers?”<br class=""></div></div></blockquote><div><br class=""></div><div>Hi Dave,</div><div>Ok. here are just a few examples: </div>Parsing and validating an ISBN code? or a (freight) container ID? or EAN13 perhaps? </div><div>of many of the typical combined article codes and product IDs that many factories and shops use? </div><div><br class=""></div><div>or: </div><div><br class=""></div><div>E.g. processing legacy files from IBM mainframes:</div><div>extract fields from ancient data records read from very old sequential files,</div><div>say, a product data record like this from a file from 1978 you’d have to unpack and process: </div><div>123534-09EVXD4568,991234,89ABCYELLOW12AGRAINESYTEMZ3453</div><div>into:</div><div>123, 534, -09, EVXD45, 68,99, 1234,99, ABC, YELLOW, 12A, GRAIN, ESYSTEM, Z3453.</div><div>product category, pcs, discount code, product code, price Yen, price $, class code, etc… </div><div>in Cobol and PL/1 records are nearly always defined with a fixed field layout like this.:</div><div>(storage was limited and very, very expensive, e.g. XML would be regarded as a </div><div>"scandalous waste" even the commas in CSV files! ) </div><div><br class=""></div><div>01 MAILING-RECORD.</div><pre class=""><div class=""> 05 COMPANY-NAME PIC X(30).</div><div class=""> 05 CONTACTS.</div><div class=""> 10 PRESIDENT.</div><div class=""> 15 LAST-NAME PIC X(15).</div><div class=""> 15 FIRST-NAME PIC X(8).</div><div class=""> 10 VP-MARKETING.</div><div class=""> 15 LAST-NAME PIC X(15).</div><div class=""> 15 FIRST-NAME PIC X(8).</div><div class=""> 10 ALTERNATE-CONTACT.</div><div class=""> 15 TITLE PIC X(10).</div><div class=""> 15 LAST-NAME PIC X(15).</div><div class=""> 15 FIRST-NAME PIC X(8).</div><div class=""> 05 ADDRESS PIC X(15).</div><div class=""> 05 CITY PIC X(15).</div><div class=""> 05 STATE PIC XX.</div><div class=""> 05 ZIP PIC 9(5).</div><div class=""><div style="font-family: Avenir; white-space: normal;"><br class=""></div><div style="font-family: Avenir; white-space: normal;">These are all character data fields here, except for the numeric ZIP field , however in Cobol it can be treated like character data. </div><div style="font-family: Avenir; white-space: normal;"><div>So here I am, having to get the data of these old Cobol production files</div><div>into a brand new Swift based accounting system of 2017, what can I do? </div><div class=""><br class=""></div><div class="">How do I unpack these records and being the data into a Swift structure or class? </div><div class="">(In Cobol I don’t have to because of the predefined fixed format record layout).</div></div><div style="font-family: Avenir; white-space: normal;"><br class=""></div><div style="font-family: Avenir; white-space: normal;">AFAIK there are no similar record structures with fixed fields like this available Swift?</div><div style="font-family: Avenir; white-space: normal;"><br class=""></div><div style="font-family: Avenir; white-space: normal;">So, the only way I can think of right now is to do it like this:</div><div style="font-family: Avenir; white-space: normal;"><br class=""></div><div style="font-family: Avenir; white-space: normal;">// mailingRecord is a Swift structure</div><div style="font-family: Avenir; white-space: normal;">struct MailingRecord</div><div style="font-family: Avenir; white-space: normal;">{</div><div style="font-family: Avenir; white-space: normal;"> var companyName: String = “no Name”</div><div style="font-family: Avenir; white-space: normal;"> var contacts: CompanyContacts</div><div style="font-family: Avenir; white-space: normal;"> .</div><div style="font-family: Avenir; white-space: normal;"> etc.. </div><div style="font-family: Avenir; white-space: normal;">}</div><div style="font-family: Avenir; white-space: normal;"><br class=""></div><div style="font-family: Avenir; white-space: normal;">// recordStr was read here with ASCII encoding</div><div style="font-family: Avenir; white-space: normal;"><br class=""></div><div style="font-family: Avenir; white-space: normal;">// unpack data in to structure’s properties, in this case all are Strings</div><div style="font-family: Avenir; white-space: normal;">mailingRecord.companyName = recordStr[ 0..<30]</div><div style="font-family: Avenir; white-space: normal;">mailingRecord.contacts.president.lastName = recordStr[30..<45]</div><div style="font-family: Avenir; white-space: normal;">mailingRecord.contacts.president.firstName = recordStr[45..<53]</div><div style="font-family: Avenir; white-space: normal;"><br class=""></div><div style="font-family: Avenir; white-space: normal;"><br class=""></div><div style="font-family: Avenir; white-space: normal;">// and so on..</div><div style="font-family: Avenir; white-space: normal;"><br class=""></div><div style="font-family: Avenir; white-space: normal;">Ever worked for e.g. a bank with thousands of these files unchanged formats for years?</div><div style="font-family: Avenir; white-space: normal;"><br class=""></div><div style="font-family: Avenir; white-space: normal;">Any alternative, convenient en simpler methods in Swift present? </div><div style="font-family: Avenir; white-space: normal;"><br class=""></div><div style="font-family: Avenir; white-space: normal;">Kind Regards</div><div style="font-family: Avenir; white-space: normal;">TedvG</div><div style="font-family: Avenir; white-space: normal;">( example of the above Cobol record borrowed from here: </div><div><font face="Avenir" class=""><span style="white-space: normal;" class=""> <a href="http://www.3480-3590-data-conversion.com/article-reading-cobol-layouts-1.html" class="">http://www.3480-3590-data-conversion.com/article-reading-cobol-layouts-1.html</a> ) </span></font></div><div style="font-family: Avenir; white-space: normal;"><br class=""></div></div></pre><div><br class=""></div><div> </div><div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><br class=""><blockquote type="cite" class=""><blockquote type="cite" class="">On 9 Feb 2017, at 16:48, Shawn Erickson <<a href="mailto:shawnce@gmail.com" class="">shawnce@gmail.com</a>> wrote:<br class=""><br class="">I also wonder what folks are actually doing that require indexing<br class="">into strings. I would love to see some real world examples of what<br class="">and why indexing into a string is needed. Who is the end consumer of<br class="">that string, etc.<br class=""><br class="">Do folks have so examples?<br class=""><br class="">-Shawn<br class=""><br class="">On Thu, Feb 9, 2017 at 6:56 AM Ted F.A. van Gaalen via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a> <<a href="mailto:swift-evolution@swift.org" class="">mailto:swift-evolution@swift.org</a>>> wrote:<br class="">Hello Hooman<br class="">That invalidates my assumptions, thanks for evaluating<br class="">it's more complex than I thought.<br class="">Kind Regards<br class="">Ted<br class=""><br class=""><blockquote type="cite" class="">On 8 Feb 2017, at 00:07, Hooman Mehr <<a href="mailto:hooman@mac.com" class="">hooman@mac.com</a> <<a href="mailto:hooman@mac.com" class="">mailto:hooman@mac.com</a>>> wrote:<br class=""><br class=""><br class=""><blockquote type="cite" class="">On Feb 7, 2017, at 12:19 PM, Ted F.A. van Gaalen via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a> <<a href="mailto:swift-evolution@swift.org" class="">mailto:swift-evolution@swift.org</a>>> wrote:<br class=""><br class="">I now assume that:<br class=""> 1. -= a “plain” Unicode character (codepoint?) can result in one glyph.=-<br class=""></blockquote><br class="">What do you mean by “plain”? Characters in some Unicode scripts are<br class="">by no means “plain”. They can affect (and be affected by) the<br class="">characters around them, they can cause glyphs around them to<br class="">rearrange or combine (like ligatures) or their visual<br class="">representation (glyph) may float in the same space as an adjacent<br class="">glyph (and seem to be part of the “host” glyph), etc. So, the<br class="">general relationship of a character and its corresponding glyph (if<br class="">there is one) is complex and depends on context and surroundings<br class="">characters.<br class=""><br class=""><blockquote type="cite" class=""> 2. -= a grapheme cluster always results in just a single glyph, true? =- <br class=""></blockquote><br class="">False<br class=""><br class=""><blockquote type="cite" class=""> 3. The only thing that I can see on screen or print are glyphs (“carvings”,visual elements that stand on their own )<br class=""></blockquote><br class="">The visible effect might not be a visual shape. It may be for example, the way the surrounding shapes change or re-arrange.<br class=""><br class=""><blockquote type="cite" class=""> 4. In this context, a glyph is a humanly recognisable visual form of a character,<br class=""></blockquote><br class="">Not in a straightforward one to one fashion, not even in Latin / Roman script.<br class=""><br class=""><blockquote type="cite" class=""> 5. On this level (the glyph, what I can see as a user) it is not relevant and also not detectable<br class=""> with how many Unicode scalars (codepoints ?), grapheme, or even on what kind<br class=""> of encoding the glyph was based upon.<br class=""></blockquote><br class="">False<br class=""><br class=""></blockquote><br class="">_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a> <<a href="mailto:swift-evolution@swift.org" class="">mailto:swift-evolution@swift.org</a>><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></blockquote><<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a>><br class=""><br class=""></blockquote><br class="">-- <br class="">-Dave<br class=""></div></div></blockquote></div><br class=""></body></html>