[swift-evolution] String update

[George Leontiev]

@Eneko While it sure seems possible to specify the type, I think this would go against the salient point "If something’s worth capturing, it’s worth giving it a name.” Putting the name further away seems like a step backward.


I could imagine a slightly more succinct syntax where things like .numberFromDigits are replaced by protocol conformance of the bound type:
```
extension Int: Regexable {
    func baseRegex<T>() -> Regex<T, Int>
}
let usPhoneNumber = (/let area: Int/.exactDigits(3) + "-").oneOrZero +
                    /let routing: Int/.exactDigits(3) + "-" +
                    /let local: Int/.exactDigits(4)
```

In this model, the `//` syntax will only be used for initial binding and swifty transformations will build the final regex.


> On Jan 16, 2018, at 9:20 AM, Eneko Alonso via swift-evolution <swift-evolution at swift.org> wrote:
> 
> Could it be possible to specify the regex type ahead avoiding having to specify the type of each captured group?
> 
> let usPhoneNumber: Regex<UnicodeScalar, (area: Int?, routing: Int, local: Int)> = /
>   (\d{3}?) -
>   (\d{3}) -
>   (\d{4}) /
> 
> “Verbose” alternative:
> 
> let usPhoneNumber: Regex<UnicodeScalar, (area: Int?, routing: Int, local: Int)> = / 
>   .optional(.numberFromDigits(.exactly(3)) + "-“) +
>   .numberFromDigits(.exactly(3)) + "-"
>   .numberFromDigits(.exactly(4)) /
> print(type(of: usPhoneNumber)) // => Regex<UnicodeScalar, (area: Int?, routing: Int, local: Int)>
> 
> 
> Thanks,
> Eneko
> 
> 
>> On Jan 16, 2018, at 8:52 AM, George Leontiev via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>> Thanks, Michael. This is very interesting!
>> 
>> I wonder if it is worth considering (for lack of a better word) *verbose* regular expression for Swift.
>> 
>> For instance, your example:
>> ```
>> let usPhoneNumber = /
>>   (let area: Int? <- \d{3}?) -
>>   (let routing: Int <- \d{3}) -
>>   (let local: Int <- \d{4}) /
>> ```
>> would become something like (strawman syntax):
>> ```
>> let usPhoneNumber = /let area: Int? <- .numberFromDigits(.exactly(3))/ + "-" +
>>                     /let routing: Int <- .numberFromDigits(.exactly(3))/ + "-"
>>                     /let local: Int <- .numberFromDigits(.exactly(4))/
>> ```
>> With this format, I also noticed that your code wouldn't match "555-5555", only "-555-5555", so maybe it would end up being something like:
>> ```
>> let usPhoneNumber = .optional(/let area: Int <- .numberFromDigits(.exactly(3))/ + "-") +
>>                     /let routing: Int <- .numberFromDigits(.exactly(3))/ + "-"
>>                     /let local: Int <- .numberFromDigits(.exactly(4))/
>> ```
>> Notice that `area` is initially a non-optional `Int`, but becomes optional when transformed by the `optional` directive.
>> Other directives may be:
>> ```
>> let decimal = /let beforeDecimalPoint: Int <-- .numberFromDigits(.oneOrMore)/ +
>>               .optional("." + /let afterDecimalPoint: Int <-- .numberFromDigits(.oneOrMore)/
>> ```
>> 
>> In this world, the `/<--/` format will only be used for explicit binding, and the rest will be inferred from generic `+` operators.
>> 
>> 
>> I also think it would be helpful if `Regex` was generic over all sequence types.
>> Going back to the phone example, this would looks something like:
>> ```
>> let usPhoneNumber = .optional(/let area: Int <- .numberFromDigits(.exactly(3))/ + "-") +
>>                     /let routing: Int <- .numberFromDigits(.exactly(3))/ + "-"
>>                     /let local: Int <- .numberFromDigits(.exactly(4))/
>> print(type(of: usPhoneNumber)) // => Regex<UnicodeScalar, (area: Int?, routing: Int, local: Int)>
>> ```
>> Note the addition of `UnicodeScalar` to the signature of `Regex`. Other interesting signatures are `Regex<JSONToken, JSONEnumeration>` or `Regex<HTTPRequestHeaderToken, HTTPRequestHeader>`. Building parsers becomes fun!
>> 
>> - George
>> 
>>> On Jan 10, 2018, at 11:58 AM, Michael Ilseman via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>> 
>>> Hello, I just sent an email to swift-dev titled "State of String: ABI, Performance, Ergonomics, and You!” at https://lists.swift.org/pipermail/swift-dev/Week-of-Mon-20180108/006407.html <https://lists.swift.org/pipermail/swift-dev/Week-of-Mon-20180108/006407.html>, whose gist can be found at https://gist.github.com/milseman/bb39ef7f170641ae52c13600a512782f <https://gist.github.com/milseman/bb39ef7f170641ae52c13600a512782f>. I posted to swift-dev as much of the content is from an implementation perspective, but it also addresses many areas of potential evolution. Please refer to that email for details; here’s the recap from it:
>>> 
>>> ### Recap: Potential Additions for Swift 5
>>> 
>>> * Some form of unmanaged or unsafe Strings, and corresponding APIs
>>> * Exposing performance flags, and some way to request a scan to populate them
>>> * API gaps
>>> * Character and UnicodeScalar properties, such as isNewline
>>> * Generalizing, and optimizing, String interpolation
>>> * Regex literals, Regex type, and generalized pattern match destructuring
>>> * Substitution APIs, in conjunction with Regexes.
>>> 
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20180116/62f3183b/attachment.html>