[swift-evolution] Strings in Swift 4

[Dave Abrahams]

One of the major (so far unstated) goals of the String rethink is to eliminate reasons for people to process textual data outside of String, though. You shouldn't have to use an array of bytes to get performance processing of ASCII, for example.  

Sent from my moss-covered three-handled family gradunza

> On Feb 9, 2017, at 6:56 PM, Shawn Erickson <shawnce at gmail.com> wrote:
> 
> 
> On Thu, Feb 9, 2017 at 5:09 PM Ted F.A. van Gaalen <tedvgiosdev at gmail.com> wrote:
>>> On 10 Feb 2017, at 00:11, Dave Abrahams <dabrahams at apple.com> 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?”
>> 
>> Hi Dave,
>> Ok. here are just a few examples: 
>> Parsing and validating an ISBN code? or a (freight) container ID? or EAN13 perhaps? 
>> of many of the typical combined article codes and product IDs that many factories and shops use? 
>> 
>> or: 
>> 
>> E.g. processing legacy files from IBM mainframes:
>> extract fields from ancient data records read from very old sequential files,
>> say, a product data record like this from a file from 1978 you’d have to unpack and process:   
>> 123534-09EVXD4568,991234,89ABCYELLOW12AGRAINESYTEMZ3453
>> into:
>> 123, 534, -09, EVXD45, 68,99, 1234,99, ABC, YELLOW, 12A, GRAIN, ESYSTEM, Z3453.
>> product category, pcs, discount code, product code, price Yen, price $, class code, etc… 
>> in Cobol and PL/1 records are nearly always defined with a fixed field layout like this.:
>> (storage was limited and very, very expensive, e.g. XML would be regarded as a 
>> "scandalous waste" even the commas in CSV files! ) 
>> 
>> 01  MAILING-RECORD.
>>        05  COMPANY-NAME            PIC X(30).
>>        05  CONTACTS.
>>            10  PRESIDENT.
>>                15  LAST-NAME       PIC X(15).
>>                15  FIRST-NAME      PIC X(8).
>>            10  VP-MARKETING.
>>                15  LAST-NAME       PIC X(15).
>>                15  FIRST-NAME      PIC X(8).
>>            10  ALTERNATE-CONTACT.
>>                15  TITLE           PIC X(10).
>>                15  LAST-NAME       PIC X(15).
>>                15  FIRST-NAME      PIC X(8).
>>        05  ADDRESS                 PIC X(15).
>>        05  CITY                    PIC X(15).
>>        05  STATE                   PIC XX.
>>        05  ZIP                     PIC 9(5).
>> 
>> These are all character data fields here, except for the numeric ZIP field , however in Cobol it can be treated like character data. 
>> So here I am, having to get the data of these old Cobol production files
>> into a brand new Swift based accounting system of 2017, what can I do?   
>> 
>> How do I unpack these records and being the data into a Swift structure or class? 
>> (In Cobol I don’t have to because of the predefined fixed format record layout).
>> 
>> AFAIK there are no similar record structures with fixed fields like this available Swift?
>> 
>> So, the only way I can think of right now is to do it like this:
>> 
>> // mailingRecord is a Swift structure
>> struct MailingRecord
>> {
>>     var  companyName: String = “no Name”
>>      var contacts: CompanyContacts
>>      .
>>      etc.. 
>> }
>> 
>> // recordStr was read here with ASCII encoding
>> 
>> // unpack data in to structure’s properties, in this case all are Strings
>> mailingRecord.companyName                       = recordStr[ 0..<30]
>> mailingRecord.contacts.president.lastName  = recordStr[30..<45]
>> mailingRecord.contacts.president.firstName = recordStr[45..<53]
>> 
>> 
>> // and so on..
>> 
>> Ever worked for e.g. a bank with thousands of these files unchanged formats for years?
>> 
>> Any alternative, convenient en simpler methods in Swift present? 
> These looks like examples of fix data format that could be parsed from a byte buffer into strings, etc. Likely little need to force them via a higher order string concept, at least not until unpacked from its compact byte form.
> 
> -Shawn 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170211/de4aa75b/attachment.html>