-
Notifications
You must be signed in to change notification settings - Fork 49
Pitch: String processing algorithms #188
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Pitch: String processing algorithms #188
Conversation
- Motivation for adding algorithms - Motivation for `CustomRegexComponent` - Design for added algorithms - Design for `CustomRegexComponent` - Add a few doc comments
Update pitch: Restructure the pitch to this structure: - Motivation for adding algorithms - Motivation for CustomRegexComponent - Design for added algorithms - Design for CustomRegexComponent Add a few doc comments. Update Foundation example.
#### Trim prefix | ||
|
||
```swift | ||
extension Collection { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I find myself squinting to see the differences between these functions. I wonder if it's easier to review if we group them by extension other than algorithms, like
extension Collection where Element: Equatable {
public func contains<S: Sequence>(_ other: S) -> Bool
public func trimmingPrefix<Prefix: Collection>(_ prefix: Prefix) -> SubSequence
}
extension BidirectionalCollection where SubSequence == Substring {
public func contains<R: RegexProtocol>(_ regex: R) -> Bool
public func starts<R: RegexProtocol>(with regex: R) -> Bool
}
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just some wordsmithing and editorial adjustments. This is looking good so far, though there's opportunity to have less redundancy.
|
||
You can conform your custom parser to `CustomRegexComponent`. Conformance is simple: implement the `match` function to return the upper bound of the matched substring, and the type represented by the matched range. It inherits from `RegexProtocol`, so you will be able to use it with all of the string algorithms that take a `RegexProtocol` type. | ||
|
||
Here, we use Foundation framework's `FloatingPointFormatStyle<Double>.Currency` as an example. `FloatingPointFormatStyle<Double>.Currency` would conform to `CustomRegexComponent` by implementing the `match` function, with `Match` being a `Double`. It could also add a static function `.localizedCurrency(code:)` as a member of `RegexProtocol`, so you can refer to it as `.localizedCurrency(code:)` in the `Regex` result builder. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It really seems like this should be merged into the "proposed solution" sub-section, where the example's fresh in the reader's mind.
Editorial changes Co-authored-by: Michael Ilseman <michael.ilseman@gmail.com>
…differences in the two sections
- Add a comparison table for Python string functions and those of Swift - Add header docs for all except for `replacing`
@itingliu let me know when's a good time to do another pass over the prose. I don't want to conflict or interrupt any reorganizing you're doing. |
…ustomMatchingRegexComponent
…iu/swift-experimental-string-processing into pr/string-processing-pitch-update
Co-authored-by: Michael Ilseman <michael.ilseman@gmail.com>
…sign; slim down future direction
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Overall LGTM. I think some of the "backwards" future direction is salvageable and should be mentioned, but it doesn't need to be presented as a big deal.
After that, ship it!
I reworked it a little bit and added it back. Thanks! |
@swift-ci please test |
* Add string processing algorithms pitch Co-authored-by: Tim Vermeulen <tvermeulen@apple.com> Co-authored-by: Michael Ilseman <michael.ilseman@gmail.com>
No description provided.