Add @RegexComponentBuilder overloads for string processing algorithm.
#334
Conversation
These overloads will allow you to write, e.g.
```swift
let _ = str.wholeMatch {
OneOrMore("a")
"+"
OneOrMore("a")
}
```
instead of
```swift
let _ = str.wholeMatch(of: Regex {
OneOrMore("a")
"+"
OneOrMore("a")
})
```
| /// - content: A closure to produce a `RegexComponent` to replace. | ||
| /// - Returns: A new collection in which all occurrences of subsequence | ||
| /// matching `regex` in `subrange` are replaced by `replacement`. | ||
| public func replacing<Replacement: Collection>( |
There was a problem hiding this comment.
I'm still not quite sure about these replace ones. With the simplest one that has default value for subrange and maxReplacements, you'd do
let _ = str.replacing(with: "xxx") {
OneOrMore("a")
"+"
OneOrMore("a")
}But this reads backwards to me and doesn't translate great.
There was a problem hiding this comment.
Good point. But seems pretty reasonable given the syntactic benefit it offers.
There was a problem hiding this comment.
ok I'll leave them here for practicality
| public func split( | ||
| maxSplits: Int = Int.max, | ||
| omittingEmptySubsequences: Bool = true, | ||
| @RegexComponentBuilder _ separator: () -> some RegexComponent |
There was a problem hiding this comment.
Should we keep this argument label, so that when the user is not using a trailing closure they will be using a separator: label to clarify the argument?
| @RegexComponentBuilder _ separator: () -> some RegexComponent | |
| @RegexComponentBuilder separator: () -> some RegexComponent |
There was a problem hiding this comment.
I changed the argument labels of the builder functions to match their non-builder counterparts.
| /// - content: A closure to produce a `RegexComponent` to replace. | ||
| /// - Returns: A new collection in which all occurrences of subsequence | ||
| /// matching `regex` in `subrange` are replaced by `replacement`. | ||
| public func replacing<Replacement: Collection>( |
There was a problem hiding this comment.
Good point. But seems pretty reasonable given the syntactic benefit it offers.
| /// - Parameter content: A closure to produce a `RegexComponent` to search for. | ||
| /// - Returns: A collection of matches of `regex`. | ||
| public func matches<R: RegexComponent>( | ||
| @RegexComponentBuilder _ content: () -> R |
There was a problem hiding this comment.
Shall we keep of:? Even though it disappears as a trailing closure, the user may choose not to use a trailing closure for clarity, e.g. prefix(where: { $0 != 1 })
There was a problem hiding this comment.
good point. I wasn't sure about this. Thanks
| /// Match part of the regex, starting at the beginning. | ||
| /// - Parameter content: A closure to produce a `RegexComponent` to match against. | ||
| /// - Returns: The match if there is one, or `nil` if none. | ||
| @available(SwiftStdlib 5.7, *) |
There was a problem hiding this comment.
No need for availability in the proposal.
|
@swift-ci please test |
These overloads will allow you to write, e.g.
instead of