DSL free functions -> types #203
Conversation
|
@swift-ci please test |
| // A convenience protocol for builtin regex components that are initialized with | ||
| // a `DSLTree` node. | ||
| internal protocol _BuiltinRegexComponent: RegexComponent { | ||
| var regex: Regex<Match> { get } |
There was a problem hiding this comment.
BTW, do we have anything in-tree that uses this as an instance instead of a static var?
There was a problem hiding this comment.
Also, I don't think we need to redeclare this, do we?
There was a problem hiding this comment.
I think custom regex types can use instance members to allow config options. We don’t have any examples in tree yet
There was a problem hiding this comment.
Good point, will remove redeclaration.
| // a `DSLTree` node. | ||
| internal protocol _BuiltinRegexComponent: RegexComponent { | ||
| var regex: Regex<Match> { get } | ||
| init(_ regex: Regex<Match>) |
There was a problem hiding this comment.
Do we want this defaulted with self.regex = regex? Or even just have this in an extension?
There was a problem hiding this comment.
Protocol initializers can only do delegate initialization, so I don’t think we can. There’s no way to express a formal guarantee that a protocol property will be a stored property.
I had the same inertia myself… |
rxwei
force-pushed
the
dsl-functions-to-types
branch
from
ee31d51 to
a109f42
Compare
Replace free functions such as `oneOrMore` with types such as `OneOrMore`. This hides overloads of free functions as initializers within those types. It also makes the DSL consistent with SwiftUI. - `oneOrMore` -> `OneOrMore` - `zeroOrMore` -> `ZeroOrMore` - `optionally` -> `Optionally` - `repeating` -> `Repeat` - `choiceOf` -> `ChoiceOf` - `capture` -> `Capture` - `tryCapture` -> `TryCapture` Note: The reason we didn't realize this was possible (e.g. in swiftlang#126) was because we were narrowly focused on including the subpattern type in the quantifier/combinator's generic parameter, i.e. `OneOrMore<Component: RegexComponent>`, which made it impossible to deduce each type's `typealias Match` from `Component`. Now we have an unconstrained generic parameter (e.g. `OneOrMore<Match>`) which gives us the full flexibility to hide `Match` deduction rules in initializers' type signatures.
rxwei
force-pushed
the
dsl-functions-to-types
branch
from
a109f42 to
f2ed846
Compare
|
@swift-ci please test |
Replace free functions such as
oneOrMorewith types such asOneOrMore. This hides overloads of free functions as initializers within those types. It also makes the DSL consistent with SwiftUI.oneOrMore->OneOrMorezeroOrMore->ZeroOrMoreoptionally->Optionallyrepeating->RepeatchoiceOf->ChoiceOfcapture->CapturetryCapture->TryCaptureNote: The reason we didn't realize this was possible (e.g. in #126) was because we were narrowly focused on including the subpattern type in the quantifier/combinator's generic parameter, i.e.
OneOrMore<Component: RegexComponent>, which made it impossible to deduce each type'stypealias MatchfromComponent. Now we have an unconstrained generic parameter (e.g.OneOrMore<Match>) which gives us the full flexibility to hideMatchdeduction rules in initializers' type signatures.Result: All non-operator top-level functions have been eliminated.