# SE-0448: Regex Lookbehind Assertions

**URL:** <https://forums.swift.org/t/se-0448-regex-lookbehind-assertions/74672>\
**Category:** Proposal Reviews\
**Created:** [September 18, 2024, 2:10am UTC](https://forums.swift.org/t/se-0448-regex-lookbehind-assertions/74672 "2024-09-18T02:10:56Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![scanon](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/scanon/32/2445_2.png) [@scanon](https://forums.swift.org/u/scanon)\
**Post date:** [September 18, 2024, 2:10am UTC](https://forums.swift.org/t/se-0448-regex-lookbehind-assertions/74672/1 "2024-09-18T02:10:56Z")

</div>

Hi everyone. The review of [SE-0448: Regex Lookbehind Assertions](https://github.com/swiftlang/swift-evolution/blob/main/proposals/0448-regex-lookbehind-assertions.md) begins now and runs through **October 1, 2024**.

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

- macOS: [https://ci.swift.org/job/swift-PR-toolchain-macos/1513/artifact/branch-main/swift-PR-76430-1513-osx.tar.gz](https://ci.swift.org/job/swift-PR-toolchain-macos/1513/artifact/branch-main/swift-PR-76430-1513-osx.tar.gz)
- Linux (Ubuntu 20.04): [https://download.swift.org/tmp/pull-request/76430/1049/ubuntu2004/PR-ubuntu2004.tar.gz](https://download.swift.org/tmp/pull-request/76430/1049/ubuntu2004/PR-ubuntu2004.tar.gz)
- Windows: [https://ci-external.swift.org/job/swift-PR-build-toolchain-windows/5484/artifact/\*zip\*/archive.zip](https://ci-external.swift.org/job/swift-PR-build-toolchain-windows/5484/artifact/*zip*/archive.zip)

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](https://github.com/apple/swift-evolution/blob/main/process.md).

Thanks for contributing to Swift!

Steve Canon  
Review Manager

---

<div class="post-metadata">

**Author:** ![benrimmington](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/benrimmington/32/695_2.png) [@benrimmington](https://forums.swift.org/u/benrimmington)\
**Post date:** [September 27, 2024, 2:15am UTC](https://forums.swift.org/t/se-0448-regex-lookbehind-assertions/74672/2 "2024-09-27T02:15:42Z")

</div>

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?)

* * *

> [@scanon](#):
>
> 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.

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

---

<div class="post-metadata">

**Author:** ![scanon](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/scanon/32/2445_2.png) [@scanon](https://forums.swift.org/u/scanon)\
**Post date:** [September 27, 2024, 11:58am UTC](https://forums.swift.org/t/se-0448-regex-lookbehind-assertions/74672/3 "2024-09-27T11:58:27Z")

</div>

> [@benrimmington](#):
>
> Will there be availability checks for regex literals?

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.

> [@benrimmington](#):
>
> How is this achieved for macOS, where the runtime component is usually preinstalled?

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.

---

<div class="post-metadata">

**Author:** ![scanon](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/scanon/32/2445_2.png) [@scanon](https://forums.swift.org/u/scanon)\
**Post date:** [October 2, 2024, 3:08pm UTC](https://forums.swift.org/t/se-0448-regex-lookbehind-assertions/74672/4 "2024-10-02T15:08:15Z")

</div>

This proposal has been [accepted](https://forums.swift.org/t/accepted-se-0448-regex-lookbehind-assertions/75111).

---

<div class="post-metadata">

**Author:** ![John\_McCall](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/john_mccall/32/1351_2.png) [@John\_McCall](https://forums.swift.org/u/John_McCall)\
**Post date:** [October 2, 2024, 5:00pm UTC](https://forums.swift.org/t/se-0448-regex-lookbehind-assertions/74672/5 "2024-10-02T17:00:41Z")

</div>

Closed on October 2, 2024, 5:00pm UTC


