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
> <[email protected]> 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
>> <[email protected] <mailto:[email protected]>> 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
>> [email protected] <mailto:[email protected]>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> _______________________________________________
> swift-evolution mailing list
> [email protected]
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
