# \[Pitch #2\] Regex Literals

**URL:** <https://forums.swift.org/t/pitch-2-regex-literals/56736>\
**Category:** Pitches\
**Created:** [April 13, 2022, 5:56pm UTC](https://forums.swift.org/t/pitch-2-regex-literals/56736 "2022-04-13T17:56:28Z")\
**Posts on this page:** 1\
**Showing post:** 37

<div class="post-metadata">

**Author:** ![Michael\_Ilseman](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/michael_ilseman/32/44640_2.png) [@Michael\_Ilseman](https://forums.swift.org/u/Michael_Ilseman)\
**Post date:** [April 15, 2022, 4:22pm UTC](https://forums.swift.org/t/pitch-2-regex-literals/56736/37 "2022-04-15T16:22:32Z")

</div>

> [@johnno1962](#):
>
> I don't recommend Swift pursues the sort of lexical cartwheels and recourse to heuristics blurring the line between lexical and Semantic analysis these languages have to resort to.

My understanding is that Swift doesn't have to resort to any blurring between lexical, syntactic, and semantic analysis. The compiler changes proposed are strictly lexical. They also prioritize preserving the meaning of existing code via the no-leading-spaces rule. A interesting discussion here could be around whether or how much this rule devalues the `/.../` syntax.

> [@johnno1962](#):
>
> deprecating using `/` as a prefix operator is going to source break a innovative and significant open source project [The Composable Architecture](https://github.com/pointfreeco/swift-composable-architecture) and a good deal of client source that uses it.

IMO, this is the most compelling counter-argument to the proposed `/.../` syntax.

> [@johnno1962](#):
>
> I'm sure however if a way could be found to include `\` in the characters that can be used to define operators the TCA folk would be only too happy.

And this, or native support for case paths, would (IMO) be the most compelling workaround.

---

_[View the full topic](https://forums.swift.org/t/pitch-2-regex-literals/56736)._