SE-0448: Regex Lookbehind Assertions

Evolution Proposal Reviews
1

Hi everyone. The review of SE-0448: Regex Lookbehind Assertions begins now and runs through October 1, 2024.

In order to try this feature out, the proposal authors have provided toolchains:

Note that there is both a compile time and a runtime component to this proposal; in order to try it out, you must take some care to ensure that the provided toolchain is used both at compile time and runtime.

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/main/process.md .

Thanks for contributing to Swift!

Steve Canon
Review Manager

9 Likes
2

I have a question about the "implications on adoption" section:

The additions described in this proposal require a new version of the standard library and runtime.

What happens when a regex literal is supported by the compiler, but isn't supported by the deployment target? (Will there be availability checks for regex literals?)

How is this achieved for macOS, where the runtime component is usually preinstalled?

1 Like
3

Yes, it's just like calling an API supported by the SDK but not the deployment target--you must be in an availability context that lets you use the feature, otherwise you get an error at compile time for literals. For the initializer from String, it will throw when run with a standard library that does not have the feature. @Michael_Ilseman has been working through the details of how this all happens, mechanically.

For simple experiments, you can set DYLD_LIBRARY_PATH to point into the toolchain runtime directory, but be aware that this gives you a stdlib that isn't quite in-sync with the rest of the OS libraries, so you may see some errors for more complex programs that interact with other runtime libraries.

I think that you can probably work around this for more sophisticated experiments by using the toolchain compiler, but including the appropriate string-processing branch as a package dependency so that it shadows the toolchain-provided APIs and is used at runtime.

4 Likes
4

This proposal has been accepted.

1 Like