Allow setting any of the three quant behaviors #311
Conversation
This also moves QuantificationBehavior from the RegexBuilder module down to _StringProcessing, and renames it RegexQuantificationBehavior.
|
@swift-ci Please test |
|
@swift-ci Please test |
|
@swift-ci Please test |
| @@ -41,7 +41,11 @@ extension AST { | |||
| case graphemeClusterSemantics // X | |||
| case unicodeScalarSemantics // u | |||
| case byteSemantics // b | |||
|
|
|||
| // Swift-only default possessive quantifier | |||
| case possessiveByDefault // t.b.d. | |||
There was a problem hiding this comment.
In general, it's fine to model swift extensions (even ones that we haven't assigned letters to) in the options here. But, I'm curious if or why it's necessary.
There was a problem hiding this comment.
It's just more of our existing AST leakage. I think it's okay since we'll want it in the AST eventually, but we still do need to audit and remove AST values from non-AST types.
| @@ -150,6 +160,9 @@ extension MatchingOptions { | |||
| case unicodeScalarSemantics | |||
| case byteSemantics | |||
|
|
|||
| // Swift-only default possessive quantifier | |||
| case possessiveByDefault | |||
There was a problem hiding this comment.
Does this need to be modeled in this way? It seems like options would just have a quantification kind in it.
There was a problem hiding this comment.
This is a bitset internally, so it's modeling the tripartite state with two Booleans and an invariant check.
| @@ -183,6 +189,46 @@ public struct RegexWordBoundaryKind: Hashable { | |||
| } | |||
| } | |||
|
|
|||
| /// Specifies how much to attempt to match when using a quantifier. | |||
| @available(SwiftStdlib 5.7, *) | |||
| public struct RegexQuantificationBehavior: Hashable { | |||
There was a problem hiding this comment.
Regex.QuantificationBehavior?
Do we want an unspecified case or do we want to model as optional behaviors?
There was a problem hiding this comment.
There's no unspecified case — eager is the default, and then you can switch to another. DSL types like OneOf take an optional behavior, with nil falling back to the behavior set via quantificationBehavior.
There was a problem hiding this comment.
But the choice of default is contextual. I think we'd want to resolve an unspecified quantification at compilation time by checking our options context. If someone had a context that explicitly overrided unspecified with .reluctant, then wanted to go back to .unspecified, how would that happen?
There was a problem hiding this comment.
The default isn't contextual, it's .eager — if someone wants to override that default for a chunk of their declaration they can, but there isn't an "unspecified" value for any of the options.
There was a problem hiding this comment.
And how would they have a non-overridable .eager subexpression within there?
|
@swift-ci Please test |
|
@swift-ci Please test |
This also moves QuantificationBehavior from the RegexBuilder module down to _StringProcessing, and renames it to RegexRepetitionBehavior.
This also moves
QuantificationBehaviorfrom theRegexBuildermodule down to_StringProcessing,and renames itRegexQuantificationBehavior.