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@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,
> whose gist can be found at
> 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@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
