Skip to content

main -> swift/main #365

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

Closed
wants to merge 33 commits into from
Closed

main -> swift/main #365

wants to merge 33 commits into from

Conversation

milseman
Copy link
Member

No description provided.

itingliu and others added 30 commits April 22, 2022 15:18
* Update Sequence/Collection polarity

* Add a note about new generics features

* Update split methods, catch some inconsistencies

* Adopt opaque parameter types where possible today

Also includes some generic naming updates and typo fixes.

* Update documentation parameters

* split(by:) -> split(separator:)
…m. (#334)

* Add `@RegexComponentBuilder` overloads for string processing algorithm.

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")
})
```
This eliminates PredicateConsumer from the implementation so that
the closure can throw.
This plumbs those parameters down into the SplitCollection type,
and removes Collection conformance for now because (a) we aren't
using it, and (b) it looks tricky to implement properly.
Better test coverage for both the regex and collection variants of
these two methods, plus overloads for contains(_:) to win over
Foundation's version from the overlay.

Also fixes an error in TwoWaySearcher that tried to offset past the
searched string's endIndex; might be a sign of something awry, but
tests seem to be otherwise succeeding.
* Mention API naming consistency
Make `~=` generic over `RegexComponent` so that one can use builder components, e.g. `OneOrMore(...)`, or custom-consuming regex components as patterns.
* Add `@RegexComponentBuilder` overloads for collection algorithms

- Add overloads per string processing proposal
- Update doc comments
- Add tests that uses the builder
- Rename `Match.swift` to `Algorithms.swift` as it contains more than
match functions now

* Update the proposal as well
- Fix spelling error in parameter name (invertion --> inversion).
- Add docs for parameters and return values.
- Use indicative instead of imperative for method/function/initializer
  abstracts.  (Match a regex. --> Matches a regex.)
- Don't use code voice in abstracts, or symbol names as English nouns.
- Use contractions per Apple style.
- Turn /// comments that contain notes for this API's implementers into
  plain // comments, to omit that content from the docs.  Move them
  before the /// comments, to keep doc comments immediately adjacent
  to the declaration they documents.
* Extension collection

* Break out long excerpts

* cleanup

* bidi split

* mystery mark

* Update Documentation/Evolution/StringProcessingAlgorithms.md

Co-authored-by: Nate Cook <[email protected]>

* split preserving

Co-authored-by: Nate Cook <[email protected]>
* API stubs for casting and named captures

* Update Sources/_StringProcessing/Regex/AnyRegexOutput.swift

Co-authored-by: Richard Wei <[email protected]>

Co-authored-by: Richard Wei <[email protected]>
The "motivation tests" still aren't working on macOS CI
* Number captures consistently
* Proper indentation
Co-authored-by: Nate Cook <[email protected]>
milseman and others added 3 commits April 26, 2022 20:45
Confirmed (using the command below) that this branch now contains only
changes to doc comments, changes to // comments where content was moved
into or out of a doc comment, and one spelling correction to code.

% git diff origin/main... |
    grep -v '^+ *///\|- *///' |
    grep -v '^@@' |
    grep -v '^ ' |
    grep -v '^+++\|^---' |
    grep -v '^diff --git' |
    grep -v '^index '

+  // Individual public API functions are in the generated Variadics.swift file.
+// For now, we use String as the source while prototyping...
+
+  // NOTE: Currently, this means we have raw quotes.
+  // Better would be to have real Swift string delimiter parsing logic.
+
+  // NOTE: traditional comments are not nested. Currently, we are neither.
+  // Traditional comments can't have `)`, not even escaped in them either, we
+  // can. Traditional comments can have `*/` in them, we can't without
+  // escaping. We don't currently do escaping.
+
-  // Finish, flush, and clear. Returns the rendered output
+  // Finish, flush, and clear.
+  //
+  // - Returns: The rendered output.
+  // Note: The `Script` enum includes the "meta" script type "Katakana_Or_Hiragana", which
+  // isn't defined by https://www.unicode.org/Public/UCD/latest/ucd/Scripts.txt,
+  // but is defined by https://www.unicode.org/Public/UCD/latest/ucd/PropertyValueAliases.txt.
+  // We may want to split it out, as it's the only case that is a union of
+  // other script types.
+
+// TODO: These should become aliases for the Block (blk) Unicode character
+// property.
+
-  // Ensures `.0` always refers to the whole match.
-  // Allows `.0` when `Match` is not a tuple.
-  func withInversion(_ invertion: Bool) -> Self {
+  func withInversion(_ inversion: Bool) -> Self {
-    if invertion {
+    if inversion {
Revise doc comments for API reference style.
@rxwei
Copy link
Contributor

rxwei commented Apr 28, 2022

We shouldn't create a PR from main directly as main's HEAD is constantly moving, and any PR that merges into main will invalidate the tests here. Instead, we should create a branch off of main and start a PR from that to swift/main, for example: #328. Detailed workflow: https://github.com/apple/swift-experimental-string-processing#integration-workflow

@milseman milseman closed this Apr 28, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants