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