The review of SE-0354: Regex Literals ran from April 28 to May 10. The core team has decided to return the proposal for revision while accepting in principle the need for a regex literal and the use of
/.../ as the delimiter. A second review with this revision is open now.
The majority of discussion in the first review was regarding the choice of delimiter, and its impact on existing source – specifically due to removal of prefix
/ operators. During the review discussion, an alternative parsing rule was established that eliminated the need to remove these operators.
The additions to the proposal consists of two parts:
- looking forward for unmatched closing parentheses within the regular expression, and only parsing the
/as a regex if there are none. This resolves ambiguity such as
f(x, /, y).reduce(/)
/as an operator if there is no second
/on the same line
Testing by the proposal authors indicate that several open-source packages that used those operators now compile cleanly with the 5.7 release branch when enabling regex literals.
Given this, the core team has decided to open a second round of review, with the new parsing rule, for further feedback. In particular, the core team would like this review to focus on other aspects of the proposal, such as multi-line non-semantic whitespace literals, and the typed capture behavior. Feedback on any unanticipated edge cases with the new parsing rule would also be appreciated.
Some reviewers expressed a desire to avoid the terse regex syntax entirely, or only allow it to be constucted at runtime, with only the DSL being provided to create them
Regex type at compile time. The core team endorses the principle of regex syntax literal as a first-class feature of the language. Regexes are a time-tested way of matching string content. Swift would take this concept, adding notable improvements such as grapheme-based matching and strongly-typed captures.
The core team agrees with the proposal authors that a succinct literal is important. Here, succinct means a single-character delimeter, matching the precedent of string, array, and dictionary literals. One of Swift's goals is clean, concise syntax. While
#/.../# could support the feature on its own, it doesn't achieve the same level of the concise syntax that can be achieved with the proposed
/.../ syntax. This is especially important with regular expressions used within the DSL, but also for other non-DSL uses such as in
Given the need for a single-character literal,
/.../ is appropriate as a term of art for regexes. Other single-character options either suffer similar ambiguities to
/, or would use a delimiter that doesn't imply regex and would perhaps have a better alternative use in future, such as
The core team acknowledges that this is a contentious decision. Many on the forum thread expressed the view that
#/.../# is more clear than the bare slash delimiter. The core team does not take this position and agrees with the proposers that
/.../ is preferable. This is primarily an aesthetic judgement, but there are also other criteria involved. In particular, it seems hard to justify why string literals have both
#" forms, while the analogous regular expression form has only
Some reviewers preferred a fuller spelling, for example
#regex(...) . Given the goal of concise syntax, the core team does not think this would be a good direction. A motivation cited for
#regex(...) was that other literals begin with
# – for example
#selector(...) . While this is true, the inference from this that that
# means literal is incorrect.
# denotes compiler integration, of which literals are a subset. However, the most common literals such as for strings or arrays do not use a
# , since it introduces unnecessary noise. The core team considers this to apply to regex literals also.
Reviewers expressed concern at the complexity of the parsing rules needed to properly disambiguate operators from delimiters. The core team notes that this kind of parsing rule is normal for Swift – a very similar situation exists for handling
< – but that this kind of parsing rule is rarely surfaced in this level of detail, so may be new for some evolution participants. The need for non-Swift compiler parsers (such as editor syntax highlighting) to be able to handle the rules is an acknowledged issue here – but the belief is the rules presented are straightforward enough to be implemented by other parsers too.
Thanks to everyone who participated in the review, which led to a much improved proposal.