Hi everyone. The second review of SE-0354: Regex Literals has concluded and the proposal has been accepted with modifications.
The second review primarily focused on the multi-line non-semantic whitespace literals. The core team agrees with the proposers that it is beneficial to have a specific lightweight syntax for these kinds of literals, and does not believe the multi-line syntax enabling non-semantic whitespace is likely to cause confusion amongst users, given the syntax requirement of a new line both directly after the #/ and before the /#.
The review did discuss the potentially surprising behavior of non-semantic whitespace between regular characters, that is:
#/
hello world
/#
where users might understand that the whitespace before hello is stripped, but not realize the whitespace between the two words is (i.e. the above is equivalent to /helloworld/). Various alternatives were discussed such as only stripping whitespace at the beginning/end of lines, or warning on bare whitespace between regular letters. The core team sees the merit of these alternatives but decided to accept the proposal as is. The introdution of a warning in the above example (supressible using \<space>) could be considered in the future.
The ability to turn off non-semantic whitespace was originally disabled in the original implementation, though this was not called out in the proposal. This was due to the challenges of interaction with the host language (Swift) and the regex DSL. The authors have since updated the proposal to allow disabling non-semantic whitespace via both (?-x:…) and \Q…\E so long as this does not span multiple lines, and the core team agrees with this modification.
Additionally, the core team has accepted a modification proposing extending the rule that regex literals not start with whitespace to also require not ending with whitespace. This means that use of the prefix / operator would still be possible in code such as:
f(/bar, /baz)
Feedback from the initial Xcode beta suggests this is the main cause of source breaks from this feature, and eliminating this would lead to almost no effective impact on source by enabling this feature via the early adoption flag in Swift 5.7. Note that this early adoption flag is likely to become part of the broader proposal of SE-0362: Piecemeal adoption of future language improvements that is currently in review.
The proposal authors have updated the proposal with these modifications, and a diff of changes can be found here.
Thank you to everyone who participated in both the first and second review. The feedback from this review was directly responsible for many improvements that made this feature a great addition to the language.
