Option APIs for RegexProtocol #171
Conversation
|
In SwiftUI, the tighter binding modifier wins. I think it'd be good to follow the same convention so when people more between result builder DSLs they don't have to turn their brain inside-out. Tighter binding winning is also consistent with regex literals and variable binding in general. |
| } else { | ||
| return input[low].lowercased() == c.lowercased() | ||
| ? input.index(after: low) | ||
| : nil |
There was a problem hiding this comment.
This code/logic is repeated a lot. Any chance to refactor it a little?
| @@ -198,7 +202,22 @@ extension DSLTree.Atom { | |||
|
|
|||
| extension DSLTree { | |||
| struct Options { | |||
| // TBD | |||
| enum Kind { | |||
There was a problem hiding this comment.
What's the difference between this an MatchingOptions?
There was a problem hiding this comment.
I flattened this out — with the SwiftUI-style options, we don't need to coalesce, so the existing MatchingOptionsSequence works fine.
Tests/RegexTests/MatchTests.swift
Outdated
| ("cafe", true), | ||
| ("CaFe", true), | ||
| ("EfAc", true)) | ||
| } |
There was a problem hiding this comment.
Thanks for the tests! What about multi-scalar expansions, like the German SS?
There was a problem hiding this comment.
I believe we need case folding to do all this properly, don't we? I'll follow up with some tests showing the holes.
natecook1000
force-pushed
the
dsl_options
branch
from
6283cd8 to
cdc1d0e
Compare
|
@swift-ci Please test Linux platform |
This adds an API to any conforming type that lets the user control
whether a match uses case sensitive comparison from within a DSL
declaration. Adding successive modifiers is equivalent to nesting
an expression in a new Regex declaration.
For example, these two regex declarations are equivalent:
```
let regexDSL = Regex {
oneOrMore {
"a"
}
.caseSensitive(false)
.caseSensitive(true)
}
let regexNested = Regex {
Regex {
oneOrMore {
"a"
}.caseSensitive(false)
}.caseSensitive(true)
}
```
natecook1000
force-pushed
the
dsl_options
branch
from
cdc1d0e to
212ce08
Compare
|
@swift-ci Please test Linux platform |
| @@ -110,6 +110,16 @@ extension AST { | |||
| } | |||
| } | |||
|
|
|||
| extension AST.MatchingOptionSequence { | |||
There was a problem hiding this comment.
FWIW, when we pay off some technical debt, DSLTree will have fewer and fewer AST constructs in it.
In general, we have 3 things, the AST's representation, the API's representation, and the model type.
Literal/AST lowers-to model
API lowers-to model
It's possible in some situations for all 3 to be the same type, or for the model to also be made public in API.
This adds an API to any conforming type that lets the user control whether a match uses case sensitive comparison from within a DSL declaration. Applying modifiers like this has the opposite precedence as a regex literal, where the nearest option setter has precedence.
For example, these two regex declarations are equivalent:
Note: This requires #168.
Note 2: More options TK once we're okay with this approach.