More updates for algorithms proposal #324
Conversation
Also includes some generic naming updates and typo fixes.
| @@ -234,7 +234,7 @@ extension Collection where Element: Equatable { | |||
| /// - Parameter other: A sequence to search for within this collection. | |||
| /// - Returns: `true` if the collection contains the specified sequence, | |||
| /// otherwise `false`. | |||
| public func contains<S: Sequence>(_ other: S) -> Bool | |||
| public func contains<C: Collection>(_ other: C) -> Bool | |||
There was a problem hiding this comment.
Would this be some Collection<Element>?
There was a problem hiding this comment.
Right, all of the sequence/collection parameters can change to that. Where there's still a <R: RegexComponent> parameter, it's because we need the component's output parameter. Those will change to e.g. func firstMatch<Output>(of regex: some RegexComponent<Output>) -> Regex<Output>.Match? when we have the primary associated type.
There was a problem hiding this comment.
Is the primary associate type tracked anywhere? Do we know when we need to integrate that?
There was a problem hiding this comment.
It's waiting on stdlib's adoption of lightweight generics. Filed #325 to track this
There was a problem hiding this comment.
And the RegexComponent primary associated type is here: #207
|
|
||
| /// Match part of the regex, starting at the beginning. | ||
| /// - Parameter r: The regex to match against. | ||
| /// - Returns: The match if there is one, or `nil` if none. | ||
| public func prefixMatch<R: RegexComponent>(of r: R) -> Regex<R.Output>.Match? | ||
| public func prefixMatch<R: RegexComponent>(of regex: R) -> Regex<R.RegexOutput>.Match? |
There was a problem hiding this comment.
Update the doc comment for r to be regex.
| @@ -234,7 +234,7 @@ extension Collection where Element: Equatable { | |||
| /// - Parameter other: A sequence to search for within this collection. | |||
| /// - Returns: `true` if the collection contains the specified sequence, | |||
| /// otherwise `false`. | |||
| public func contains<S: Sequence>(_ other: S) -> Bool | |||
| public func contains<C: Collection>(_ other: C) -> Bool | |||
There was a problem hiding this comment.
It's waiting on stdlib's adoption of lightweight generics. Filed #325 to track this
| public func split<R: RegexComponent>(by separator: R) -> some Collection<Substring> | ||
| /// elements. | ||
| public func split( | ||
| by separator: some RegexComponent, |
There was a problem hiding this comment.
Do we want to drop by and call it
public func split(separator... That would match the existing String.split
There was a problem hiding this comment.
I'm a little nervous about some of the overloads we already have in the stdlib — let me take a quick look.
There was a problem hiding this comment.
Okay, this should be safe — when someone has a type-unconstrained function reference, they'll still get the current split(separator:maxSplits:omittingEmptySubsequences:) method, because it's more tightly specified (i.e., to Character, instead of a generic collection). I don't think adopting the lightweight generics syntax will change the story here.
There was a problem hiding this comment.
Even if this is from _StringProcessing instead of Swift?
There was a problem hiding this comment.
I added tests to make sure you still get the stdlib versions here: https://github.com/apple/swift-experimental-string-processing/pull/330/files#diff-3d2dc8728c9cb47deca496d7122ae9cd2e49118aa79f65f3b3c730c1adc51078R139-R143
|
@swift-ci please test |
This updates the Sequence/Collection constraints for several methods' parameters, adds missing parameters to the two
splitvariations, and adopts opaque parameter types where allowed today.