SE-0351 (second review): Regex Builder DSL

Ben_Cohen · 2022-07-06T09:21:42.692Z

Hi everyone. The second review of SE-0351: Regex Builder DSL begins now and runs through July 14th, 2022.

This second revision of the proposal incorporates feedback from the first review, as well as some updates from the proposal authors.

A summary of the updates since the first review:

Changes:

Capture now takes throwing closures
Rename Output associated type to RegexOutput
Define primary associated type for RegexComponent
Introduce a One type for disambiguating components from modifiers

Clarifications:

Clarify that RegexComponent and Regex: RegexComponent will be in the stdlib, not in RegexBuilder module.
Flesh out detailed design, driven by example, moving API definition to a collapsible section. This is so that the complex result builder machinery doesn't obscure the API design.
Add alternative considered section about unifying Capture and TryCapture.

A full diff can be found here

Reviews are an important part of the Swift evolution process. All review feedback should be either on this forum thread or, if you would like to keep your feedback private, directly to me as the review manager by email or by direct message. When emailing directly, please keep the proposal link at the top of the message.

What goes into a review?

The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift. When writing your review, here are some questions you might want to answer in your review:

What is your evaluation of the proposal?
Is the problem being addressed significant enough to warrant a change to Swift?
Does this proposal fit well with the feel and direction of Swift?
If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

More information about the Swift evolution process is available at

https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

Ben Cohen
Review Manager

paiv · 2022-07-06T18:34:54.995Z

There is a discrepancy between SE-0351 and SE-0363 in how anchorsMatchLineEndings is defined

SE-0351

  /// This anchor is equivalent to `^` in regex syntax when the `m` option
  /// has been enabled or `anchorsMatchLineEndings(true)` has been called.
  public static var startOfLine: Anchor { get }

SE-0363

This option applies only to anchors used in regex syntax. The anchors defined in RegexBuilder are specific about matching at the start/end of the input or the line, and therefore are not affected by this option.

Last time I checked the behavior defined in SE-0363 was not implemented.

https://forums.swift.org/t/se-0363-unicode-for-string-processing/
https://forums.swift.org/t/regexbuilder-line-anchors/

Michael_Ilseman · 2022-07-13T00:25:50.645Z

paiv:

There is a discrepancy between SE-0351 and SE-0363 in how anchorsMatchLineEndings is defined

SE-0351
  /// This anchor is equivalent to `^` in regex syntax when the `m` option
  /// has been enabled or `anchorsMatchLineEndings(true)` has been called.
  public static var startOfLine: Anchor { get }
SE-0363

This option applies only to anchors used in regex syntax. The anchors defined in RegexBuilder are specific about matching at the start/end of the input or the line, and therefore are not affected by this option.

What is the discrepancy? They seem to be saying the same thing: .startOfLine matches at the start of a line. The literal equivalent is /(?m:^)/ or /^/.anchorsMatchLineEndings(true).

paiv:

Last time I checked the behavior defined in SE-0363 was not implemented.

This is a bug, I opened Issue 571

paiv · 2022-07-13T04:47:23.909Z

After reading it back a couple of times, I agree the intended meaning is the same.

  /// This anchor is equivalent to `^` in regex syntax when the `m` option
  /// has been enabled or `anchorsMatchLineEndings(true)` has been called.
  public static var startOfLine: Anchor { get }

On the first read what was confusing: one could not call anchorsMatchLineEndings() inside a textual regex, so you have to call anchorsMatchLineEndings() in regex builder for it to be equivalent to textual ^. Which was observed in the currently released swift compiler.

Ben_Cohen · 2022-07-15T14:23:14.425Z

Review Conclusion

The proposal has been accepted.