[swift-evolution] [Pitch] Raw mode string literals

[John Holdsworth]

Well, this hasn’t exactly gone in the direction I was expecting. Are raw literals off the table?

I have plenty of opinions about how to integrate Regex though. It’s not the literal that’s
the problem but the operators that surround it and these operators need to allow you to:
check for a match, get the match or groups, replace matches, iterate over matches etc.

One notion I explored was the idea that in the same way an index or key of a collection
refers to a subset of the data, subscripting using a string (regex) on a string refers to
a subset of the string, It's also atomic so you don’t have to worry about precedence.

Bear with me, It works out better than you might expect once you get used to the idea.
It’s certainly very succinct for common cases.

var input = "Now is the time for all good men to come to the aid of the party"

// basic regex match
input["\\w+"] != nil

// replace by assignment
input["men"] = "folk"
print(input)

// indiviual groups can be accessed
input["(all) (\\w+)", 2]

// and assigned to
input["the (\\w+)", 1] = "_$1_"
print(input)

Operators only get you so far though. This is the point where I wished
it was possible to define a setter for a subscript type without a getter.

// capitalising words using closure
print(input.replacing(pattern: "(_?)(\\w)(\\w*)") {
    (groups, stop) in
    return groups[1]!+groups[2]!.uppercased()+groups[3]!
})

// parsing a properties file
let props = """
    name1 = value1
    name2 = value2
    """

var params = [String: String]()
for groups in props.matching(pattern: "(\\w+)\\s*=\\s*(.*)") {
    params[String(groups[1]!)] = String(groups[2]!)
}

I prepared a playground taking this idea to it’s illogical conclusion.



John


> On 25 Nov 2017, at 00:25, Chris Lattner <clattner at nondot.org> wrote:
> 
> 
> 
>> On Nov 24, 2017, at 4:15 PM, Chris Lattner <clattner at nondot.org <mailto:clattner at nondot.org>> wrote:
>> 
>>> 
>>> than the same type having a collection of named matches using the usual Perl syntax?
>>> 
>>>   if case /(?<firstName>[a-zA-Z]+) (?<lastName>[a-zA-Z]+)/ = getSomeString() {
>>>     print(Regex.captured["firstName"], Regex.captured["lastName"])
>>>   }
>> 
>> Personally, I really don’t like this.  It turns a structured problem into one that violates DRY and loses the structure inherent in the solution.  Also, while theoretically the dictionary could be optimized away, in practice that would be difficult to do without heroics.
>> 
> 
> One other minor and obscure point: if the compiler is aware of the regex grammar it can properly type the matches, I can imagine the following cases:
> 
> if case /(let name: [a-zA-Z]+) (let count: Int)/ = getSomeString() {
>    print(name, count)
> }
> 
> -> name has type String, count has type Int (and matches [0-9]+)
> 
> 
> if case /(let name: [a-zA-Z]+)? (let count: Int)/ = getSomeString() {
>    print(name, count)
> }
> 
> -> name has type String?
> 
> if case /(let name: [a-zA-Z]+)* (let count: Int)/ = getSomeString() {
>    print(name, count)
> }
> 
> -> name has type [String]
> 
> etc.  Even if we don’t have a “default regex” for types, it would still be awesome to be able to write:
> 
> 
> if case /(let name: [a-zA-Z]+) (let count: Int: [0-9]+)/ = getSomeString() {
>    print(name, count)
> }
> 
> and have that transparently invoke and check the Int?(string) failable initializer.
> 
> -Chris
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171125/54ae41f6/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: SwiftRegex4.playground.zip
Type: application/zip
Size: 16351 bytes
Desc: not available
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171125/54ae41f6/attachment.zip>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171125/54ae41f6/attachment-0001.html>