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> 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 > > _______________________________________________ > 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