Empower String type with regular expression


(John Joyce) #1

I know this is an old thread already, but this sure would be one of the major breakout pieces of functionality.
If Swift had native regular expressions, without all the noise you see in the Objective-C API that exposes ICU regular expressions, the adoption rate would be huge.
If they were *truly* native, as in somebody sat down and built an NFA (or one of the fancier approaches that mixes with DFA) state machine, Swift's best-in-class Unicode support would and could result in amazing things.
It'd boost the scripting use of Swift tremendously and seal the deal as a server side language.

···

> On Dec 8, 2015, at 12:14 PM, Jerome Paschoud via swift-evolution <swift-evolution at swift.org <https://lists.swift.org/mailman/listinfo/swift-evolution>> wrote:
>
> I would like to see the String type to support regular expression per default. I think that a language that advertise itself as being a good scripting language should provide in its default implementation an easy way (=~ for example in Perl) to use regular expressions. I know that one can use the NSRegularExpression, but who really what to first create an NSRegularExpression object(whit all the nice escaping operation that come with every \), then get a NSTextCheckingResult, then get a range (and what I mean is a NSRange and not a NSRange<String.Index>) and finally perform slicing of your original string.

Just MHO, but I’d really really like to see proper regex support in Swift someday.

I think it could fit naturally into the pattern matching syntax we already have - the obvious syntax for this pattern would use // delimiters.

It is also probably worth burning first-class language support for regexes. This would allow specifying variable captures inline in the pattern, would allow flexible syntax for defining regexes, support powerful extensions to the base regex model (e.g. Perl 6 style), and would provide better compile-time checking and error recovery for mistakes.

-Chris


Split line on a separator with optional whitespace
(Chris Lattner) #2

Totally agreed. switch on a string with a bunch of regexes being matched should turn into a parallel state machine, just like a lexer :-)

-Chris

···

On Jan 1, 2016, at 4:44 PM, John Joyce via swift-evolution <swift-evolution@swift.org> wrote:

It is also probably worth burning first-class language support for regexes. This would allow specifying variable captures inline in the pattern, would allow flexible syntax for defining regexes, support powerful extensions to the base regex model (e.g. Perl 6 style), and would provide better compile-time checking and error recovery for mistakes.

-Chris

I know this is an old thread already, but this sure would be one of the major breakout pieces of functionality.
If Swift had native regular expressions, without all the noise you see in the Objective-C API that exposes ICU regular expressions, the adoption rate would be huge.
If they were *truly* native, as in somebody sat down and built an NFA (or one of the fancier approaches that mixes with DFA) state machine, Swift's best-in-class Unicode support would and could result in amazing things.
It'd boost the scripting use of Swift tremendously and seal the deal as a server side language.


(Austin Zheng) #3

+1 on first-class regex support/pattern matching on regex patterns.

There was a thread a while ago discussing compile-time code generation, and
if I recall correctly one of the stated use cases was
'compiling'/'building' (don't know the real terminology) regex literals at
compile-time. Is there a bigger overall vision for this sort of feature, or
would it be better to just focus on better regex support?

Best,
Austin

···

On Sun, Jan 3, 2016 at 1:35 PM, Chris Lattner via swift-evolution < swift-evolution@swift.org> wrote:

On Jan 1, 2016, at 4:44 PM, John Joyce via swift-evolution < > swift-evolution@swift.org> wrote:

It is also probably worth burning first-class language support for regexes. This would allow specifying variable captures inline in the pattern, would allow flexible syntax for defining regexes, support powerful extensions to the base regex model (e.g. Perl 6 style), and would provide better compile-time checking and error recovery for mistakes.

-Chris

I know this is an old thread already, but this sure would be one of the
major breakout pieces of functionality.
If Swift had native regular expressions, without all the noise you see in
the Objective-C API that exposes ICU regular expressions, the adoption rate
would be huge.
If they were *truly* native, as in somebody sat down and built an NFA (or
one of the fancier approaches that mixes with DFA) state machine, Swift's
best-in-class Unicode support would and could result in amazing things.
It'd boost the scripting use of Swift tremendously and seal the deal as a
server side language.

Totally agreed. switch on a string with a bunch of regexes being matched
should turn into a parallel state machine, just like a lexer :slight_smile:

-Chris

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Vincent Esche) #4

There is actually a Rust crate doing exactly that: https://github.com/jneem/regex-dfa
Rust however has powerful compile-time macros, enabling this, which Swift doesn’t (yet?).

···

On 04 Jan 2016, at 02:53, Austin Zheng via swift-evolution <swift-evolution@swift.org> wrote:

+1 on first-class regex support/pattern matching on regex patterns.

There was a thread a while ago discussing compile-time code generation, and if I recall correctly one of the stated use cases was 'compiling'/'building' (don't know the real terminology) regex literals at compile-time. Is there a bigger overall vision for this sort of feature, or would it be better to just focus on better regex support?

Best,
Austin

On Sun, Jan 3, 2016 at 1:35 PM, Chris Lattner via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

On Jan 1, 2016, at 4:44 PM, John Joyce via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

It is also probably worth burning first-class language support for regexes. This would allow specifying variable captures inline in the pattern, would allow flexible syntax for defining regexes, support powerful extensions to the base regex model (e.g. Perl 6 style), and would provide better compile-time checking and error recovery for mistakes.

-Chris

I know this is an old thread already, but this sure would be one of the major breakout pieces of functionality.
If Swift had native regular expressions, without all the noise you see in the Objective-C API that exposes ICU regular expressions, the adoption rate would be huge.
If they were *truly* native, as in somebody sat down and built an NFA (or one of the fancier approaches that mixes with DFA) state machine, Swift's best-in-class Unicode support would and could result in amazing things.
It'd boost the scripting use of Swift tremendously and seal the deal as a server side language.

Totally agreed. switch on a string with a bunch of regexes being matched should turn into a parallel state machine, just like a lexer :slight_smile:

-Chris

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution


(Trent Nadeau) #5

Also https://github.com/rust-lang-nursery/regex, which is the process of
possibly being standardized either in the Rust stdlib or as a fully
supported crate (library). That crate is based on
https://github.com/google/re2 that is written in C++. Both could be used
for implementation ideas.

···

On Mon, Jan 4, 2016 at 9:52 AM, Vincent Esche via swift-evolution < swift-evolution@swift.org> wrote:

There is actually a Rust crate doing exactly that:
https://github.com/jneem/regex-dfa
Rust however has powerful compile-time macros, enabling this, which Swift
doesn’t (yet?).

On 04 Jan 2016, at 02:53, Austin Zheng via swift-evolution < > swift-evolution@swift.org> wrote:

+1 on first-class regex support/pattern matching on regex patterns.

There was a thread a while ago discussing compile-time code generation,
and if I recall correctly one of the stated use cases was
'compiling'/'building' (don't know the real terminology) regex literals at
compile-time. Is there a bigger overall vision for this sort of feature, or
would it be better to just focus on better regex support?

Best,
Austin

On Sun, Jan 3, 2016 at 1:35 PM, Chris Lattner via swift-evolution < > swift-evolution@swift.org> wrote:

On Jan 1, 2016, at 4:44 PM, John Joyce via swift-evolution < >> swift-evolution@swift.org> wrote:

It is also probably worth burning first-class language support for regexes. This would allow specifying variable captures inline in the pattern, would allow flexible syntax for defining regexes, support powerful extensions to the base regex model (e.g. Perl 6 style), and would provide better compile-time checking and error recovery for mistakes.

-Chris

I know this is an old thread already, but this sure would be one of the
major breakout pieces of functionality.
If Swift had native regular expressions, without all the noise you see in
the Objective-C API that exposes ICU regular expressions, the adoption rate
would be huge.
If they were *truly* native, as in somebody sat down and built an NFA (or
one of the fancier approaches that mixes with DFA) state machine, Swift's
best-in-class Unicode support would and could result in amazing things.
It'd boost the scripting use of Swift tremendously and seal the deal as a
server side language.

Totally agreed. switch on a string with a bunch of regexes being matched
should turn into a parallel state machine, just like a lexer :slight_smile:

-Chris

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

--
Trent Nadeau


(Patrick Gili) #6

There have been several threads that have discussed the notion of a regular expression literals. However, I didn't see anyone putting together a formal proposal, and hence I took the liberty to do so. I would appreciate discussion and comments on the proposal:

Regular Expression Literals
Proposal: [SE-NNNN] (https://github/apple/swift-evolution/blob/master/proposals/NNNN-name.md)
Author: Patrick Gili (https://github.com/gili-patrick-r)
Status: Awaiting review
Review manager: TBD
Introduction
The Swift language has no native support for regular expressions, which makes working with regular expressions in Swift awkward, tedious, and error prone. This proposal describes the addition of regular expressions literals to Swift.

Swift-evolution thread: Empower String type with regular expression <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151228/005126.html>
Motivation
The definition of a pattern used by a regular expression is complicated by the fact that Swift does not support raw string literals (i.e., string literals that do not process character escapes or interpolation) or regular expression literals similar to Perl or Ruby. Rather, Swift only supports C-style string literals with support for interpolation. C-style string literals require a backslash to escape a backslash. The patterns representing regular expressions make frequent use of the backslash, and hence patterns represented by a Swift string literal become unreadable and difficult to maintain. For example, consider the following pattern to match and parse URLs:

^(https?:\/\/)?([\da-z\.-]+)\.([a-z\.]{2,6})([\/\w \.-]*)*\/?$
To define this pattern in Swift, an application needs to define a string, such as

let pattern = "^(https?:\\/\\/)?([\\da-z\\.-]+)\\.([a-z\\.]{2,6})([\\/\\w \\.-]*)*\\/?$"
This later is obviously difficult to read and maintain.

Proposed solution
The proposed solution is to add regular expression literals to Swift, similar to regular expression literal support by other languages, such as Perl and Ruby. Regular expression literals differ from raw string literals in two primary ways. First, regular expression literals support string interpolation of the pattern, which allows an application to construct a regular expression at run-time. Second, a regular expression literal creates an instance of a NSRegularExpression, rather than an instance of String. The following example declares a regular expression for the purpose of matching and parsing URIs with a specified scheme:

let scheme = "https"
let urlRegex = /^(\(scheme)?:\/\/)?([\da-z\.-]+)\.([a-z\.]{2,6})([\/\w \.-]*)*\/?$/
To make regular expression literals effective, it must be possible to replace the creation of any instance of NSRegularExpression. The initializer for NSRegularExpression accepts a string describing the pattern and a set of options. To support these options, a regular expression literal accepts a list of zero or more options after the delimiter closing the pattern. For example, consider a regular expression to match and parse email addresses.

let emailRegex = /^([a-z0-9_\.-]+)@([\da-z\.-]+)\.([a-z\.]{2,6})$/
This regular expression will match "john.appleseed@apple.com"", but not "JOHN.APPLESEED@APPLE.COM". The regular expression has to allow for this, as email addresses are not case sensitive. Rather than add the complexity to the pattern to account for this, the following example achieves the same:

let emailRegex = /^([a-z0-9_\.-]+)@([\da-z\.-]+)\.([a-z\.]{2,6})$/i
In this case, the "i" following the delimiter closing the pattern maps to RegularExpressionOption.CaseInsensitive.

Detailed design
The following modification to the grammar of a literal adds support for regular expression literals:

literal → numeric-literal | string-literal | boolean-literal | regex-literal | nil-literal

The following grammar describes a regular expression literal:

regex-literal → static-regex-literal | interpolated-regex-literal

static-regex-literal → / patternopt / regex-optionsopt
pattern → pattern_item patternopt
pattern_item → any Unicode scalar value except /, U+000A, or U+000D

interpolated-string-literal → / interpolated-patternopt / regex-optionsopt
interpolated_pattern → interpolated_pattern_item interpolated_patternopt
interpolated_pattern_item → ( expression ) | pattern_item

regex-options → regex-option | regex-optionopt
regex_option → i | x | q | s | m | d | b

The following table summarize the regular expression options:

Option RegularExpressionOption
i CaseInsensitive
x AllowCommentsAndWhitespace
q IgnoreMetacharacters
s DotMatchesLineSeparations
m AnchorsMatchLines
d UseUnixLineSeparators
b UseUnicodeWordBoundaries
Impact on existing code
The use of regular expression literals is opt-in, and hence there is no impact to existing code.

Alternatives considered
There have been several threads on the swift-evoluation mailing list that have discussed alternatives to regular expression literals.

String literal suffixes for defining types <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151214/002193.html> discussed string literals with a single character appended after the closing delimiter to denote the type. For example, the string literal r"\d+" in Python denotes a regular expression literal. However, this approach suffers from two disadvantages: 1) it does not support string interpolation in the pattern, and 2) it uses double-quotes for the delimiter, which appears more frequently in regular expressions than the forward slash.

Muli-line string literals <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151214/002325.html> discussed string literals spanning more than one line. This would be a worthy addition to the regular expression literal discussed in this proposal. We should consider modifying the grammar to support this. However, I wanted to introduce changes incrementally to maintain focus.


(Patrick Gili) #7

Here is the link to the proposal on GitHub:

https://github.com/gili-patrick-r/swift-evolution/blob/master/proposals/NNNN-regular-expression-literals.md

Cheers,
-Patrick

···

On Jan 31, 2016, at 11:32 AM, Patrick Gili <gili.patrick.r@gili-labs.com> wrote:

There have been several threads that have discussed the notion of a regular expression literals. However, I didn't see anyone putting together a formal proposal, and hence I took the liberty to do so. I would appreciate discussion and comments on the proposal:

Regular Expression Literals
Proposal: [SE-NNNN] (https://github/apple/swift-evolution/blob/master/proposals/NNNN-name.md)
Author: Patrick Gili (https://github.com/gili-patrick-r)
Status: Awaiting review
Review manager: TBD
Introduction
The Swift language has no native support for regular expressions, which makes working with regular expressions in Swift awkward, tedious, and error prone. This proposal describes the addition of regular expressions literals to Swift.

Swift-evolution thread: Empower String type with regular expression <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151228/005126.html>
Motivation
The definition of a pattern used by a regular expression is complicated by the fact that Swift does not support raw string literals (i.e., string literals that do not process character escapes or interpolation) or regular expression literals similar to Perl or Ruby. Rather, Swift only supports C-style string literals with support for interpolation. C-style string literals require a backslash to escape a backslash. The patterns representing regular expressions make frequent use of the backslash, and hence patterns represented by a Swift string literal become unreadable and difficult to maintain. For example, consider the following pattern to match and parse URLs:

^(https?:\/\/)?([\da-z\.-]+)\.([a-z\.]{2,6})([\/\w \.-]*)*\/?$
To define this pattern in Swift, an application needs to define a string, such as

let pattern = "^(https?:\\/\\/)?([\\da-z\\.-]+)\\.([a-z\\.]{2,6})([\\/\\w <smb://///w> \\.- <smb://.->]*)*\\/?$"
This later is obviously difficult to read and maintain.

Proposed solution
The proposed solution is to add regular expression literals to Swift, similar to regular expression literal support by other languages, such as Perl and Ruby. Regular expression literals differ from raw string literals in two primary ways. First, regular expression literals support string interpolation of the pattern, which allows an application to construct a regular expression at run-time. Second, a regular expression literal creates an instance of a NSRegularExpression, rather than an instance of String. The following example declares a regular expression for the purpose of matching and parsing URIs with a specified scheme:

let scheme = "https"
let urlRegex = /^(\(scheme)?:\/\/)?([\da-z\.-]+)\.([a-z\.]{2,6})([\/\w \.-]*)*\/?$/
To make regular expression literals effective, it must be possible to replace the creation of any instance of NSRegularExpression. The initializer for NSRegularExpression accepts a string describing the pattern and a set of options. To support these options, a regular expression literal accepts a list of zero or more options after the delimiter closing the pattern. For example, consider a regular expression to match and parse email addresses.

let emailRegex = /^([a-z0-9_\.-]+)@([\da-z\.-]+)\.([a-z\.]{2,6})$/
This regular expression will match "john.appleseed@apple.com <mailto:john.appleseed@apple.com>"", but not "JOHN.APPLESEED@APPLE.COM <mailto:JOHN.APPLESEED@apple.com>". The regular expression has to allow for this, as email addresses are not case sensitive. Rather than add the complexity to the pattern to account for this, the following example achieves the same:

let emailRegex = /^([a-z0-9_\.-]+)@([\da-z\.-]+)\.([a-z\.]{2,6})$/i
In this case, the "i" following the delimiter closing the pattern maps to RegularExpressionOption.CaseInsensitive.

Detailed design
The following modification to the grammar of a literal adds support for regular expression literals:

literal → numeric-literal | string-literal | boolean-literal | regex-literal | nil-literal

The following grammar describes a regular expression literal:

regex-literal → static-regex-literal | interpolated-regex-literal

static-regex-literal → / patternopt / regex-optionsopt
pattern → pattern_item patternopt
pattern_item → any Unicode scalar value except /, U+000A, or U+000D

interpolated-string-literal → / interpolated-patternopt / regex-optionsopt
interpolated_pattern → interpolated_pattern_item interpolated_patternopt
interpolated_pattern_item → ( expression ) | pattern_item

regex-options → regex-option | regex-optionopt
regex_option → i | x | q | s | m | d | b

The following table summarize the regular expression options:

Option RegularExpressionOption
i CaseInsensitive
x AllowCommentsAndWhitespace
q IgnoreMetacharacters
s DotMatchesLineSeparations
m AnchorsMatchLines
d UseUnixLineSeparators
b UseUnicodeWordBoundaries
Impact on existing code
The use of regular expression literals is opt-in, and hence there is no impact to existing code.

Alternatives considered
There have been several threads on the swift-evoluation mailing list that have discussed alternatives to regular expression literals.

String literal suffixes for defining types <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151214/002193.html> discussed string literals with a single character appended after the closing delimiter to denote the type. For example, the string literal r"\d+" in Python denotes a regular expression literal. However, this approach suffers from two disadvantages: 1) it does not support string interpolation in the pattern, and 2) it uses double-quotes for the delimiter, which appears more frequently in regular expressions than the forward slash.

Muli-line string literals <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151214/002325.html> discussed string literals spanning more than one line. This would be a worthy addition to the regular expression literal discussed in this proposal. We should consider modifying the grammar to support this. However, I wanted to introduce changes incrementally to maintain focus.


(Patrick Gili) #8

There is one thing I want to discuss with regard to this proposal. I think NSRegularExpression is part of the standard library. If Swift were to support regular expression literal, wouldn't it make sense to move NSRegularExpression to the foundation?

Cheers,
-Patrick

···

On Jan 31, 2016, at 11:32 AM, Patrick Gili <gili.patrick.r@gili-labs.com> wrote:

There have been several threads that have discussed the notion of a regular expression literals. However, I didn't see anyone putting together a formal proposal, and hence I took the liberty to do so. I would appreciate discussion and comments on the proposal:

Regular Expression Literals
Proposal: [SE-NNNN] (https://github/apple/swift-evolution/blob/master/proposals/NNNN-name.md)
Author: Patrick Gili (https://github.com/gili-patrick-r)
Status: Awaiting review
Review manager: TBD
Introduction
The Swift language has no native support for regular expressions, which makes working with regular expressions in Swift awkward, tedious, and error prone. This proposal describes the addition of regular expressions literals to Swift.

Swift-evolution thread: Empower String type with regular expression <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151228/005126.html>
Motivation
The definition of a pattern used by a regular expression is complicated by the fact that Swift does not support raw string literals (i.e., string literals that do not process character escapes or interpolation) or regular expression literals similar to Perl or Ruby. Rather, Swift only supports C-style string literals with support for interpolation. C-style string literals require a backslash to escape a backslash. The patterns representing regular expressions make frequent use of the backslash, and hence patterns represented by a Swift string literal become unreadable and difficult to maintain. For example, consider the following pattern to match and parse URLs:

^(https?:\/\/)?([\da-z\.-]+)\.([a-z\.]{2,6})([\/\w \.-]*)*\/?$
To define this pattern in Swift, an application needs to define a string, such as

let pattern = "^(https?:\\/\\/)?([\\da-z\\.-]+)\\.([a-z\\.]{2,6})([\\/\\w <smb://///w> \\.- <smb://.->]*)*\\/?$"
This later is obviously difficult to read and maintain.

Proposed solution
The proposed solution is to add regular expression literals to Swift, similar to regular expression literal support by other languages, such as Perl and Ruby. Regular expression literals differ from raw string literals in two primary ways. First, regular expression literals support string interpolation of the pattern, which allows an application to construct a regular expression at run-time. Second, a regular expression literal creates an instance of a NSRegularExpression, rather than an instance of String. The following example declares a regular expression for the purpose of matching and parsing URIs with a specified scheme:

let scheme = "https"
let urlRegex = /^(\(scheme)?:\/\/)?([\da-z\.-]+)\.([a-z\.]{2,6})([\/\w \.-]*)*\/?$/
To make regular expression literals effective, it must be possible to replace the creation of any instance of NSRegularExpression. The initializer for NSRegularExpression accepts a string describing the pattern and a set of options. To support these options, a regular expression literal accepts a list of zero or more options after the delimiter closing the pattern. For example, consider a regular expression to match and parse email addresses.

let emailRegex = /^([a-z0-9_\.-]+)@([\da-z\.-]+)\.([a-z\.]{2,6})$/
This regular expression will match "john.appleseed@apple.com <mailto:john.appleseed@apple.com>"", but not "JOHN.APPLESEED@APPLE.COM <mailto:JOHN.APPLESEED@apple.com>". The regular expression has to allow for this, as email addresses are not case sensitive. Rather than add the complexity to the pattern to account for this, the following example achieves the same:

let emailRegex = /^([a-z0-9_\.-]+)@([\da-z\.-]+)\.([a-z\.]{2,6})$/i
In this case, the "i" following the delimiter closing the pattern maps to RegularExpressionOption.CaseInsensitive.

Detailed design
The following modification to the grammar of a literal adds support for regular expression literals:

literal → numeric-literal | string-literal | boolean-literal | regex-literal | nil-literal

The following grammar describes a regular expression literal:

regex-literal → static-regex-literal | interpolated-regex-literal

static-regex-literal → / patternopt / regex-optionsopt
pattern → pattern_item patternopt
pattern_item → any Unicode scalar value except /, U+000A, or U+000D

interpolated-string-literal → / interpolated-patternopt / regex-optionsopt
interpolated_pattern → interpolated_pattern_item interpolated_patternopt
interpolated_pattern_item → ( expression ) | pattern_item

regex-options → regex-option | regex-optionopt
regex_option → i | x | q | s | m | d | b

The following table summarize the regular expression options:

Option RegularExpressionOption
i CaseInsensitive
x AllowCommentsAndWhitespace
q IgnoreMetacharacters
s DotMatchesLineSeparations
m AnchorsMatchLines
d UseUnixLineSeparators
b UseUnicodeWordBoundaries
Impact on existing code
The use of regular expression literals is opt-in, and hence there is no impact to existing code.

Alternatives considered
There have been several threads on the swift-evoluation mailing list that have discussed alternatives to regular expression literals.

String literal suffixes for defining types <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151214/002193.html> discussed string literals with a single character appended after the closing delimiter to denote the type. For example, the string literal r"\d+" in Python denotes a regular expression literal. However, this approach suffers from two disadvantages: 1) it does not support string interpolation in the pattern, and 2) it uses double-quotes for the delimiter, which appears more frequently in regular expressions than the forward slash.

Muli-line string literals <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151214/002325.html> discussed string literals spanning more than one line. This would be a worthy addition to the regular expression literal discussed in this proposal. We should consider modifying the grammar to support this. However, I wanted to introduce changes incrementally to maintain focus.


(Chris Lattner) #9

There have been several threads that have discussed the notion of a regular expression literals. However, I didn't see anyone putting together a formal proposal, and hence I took the liberty to do so. I would appreciate discussion and comments on the proposal:

I am +1 on the concept of adding regex literals to Swift, but -1 on this proposal.

Specifically, instead of introducing regex literals, I’d suggest that you investigate introducing regex’s to the pattern grammar, which is what Swift uses for matching already. Regex’s should be usable in the cases of a switch, for example. Similarly, they should be able to bind variables directly to subpatterns.

Further, I highly recommend checking out Perl 6’s regular expressions. They are a community that has had an obsessive passion for regular expressions, and in Perl 6 they were given the chance to reinvent the wheel based on what they learned. What they came up with is very powerful, and pretty good all around.

-Chris

···

On Jan 31, 2016, at 8:32 AM, Patrick Gili via swift-evolution <swift-evolution@swift.org> wrote:

Regular Expression Literals
Proposal: [SE-NNNN] (https://github/apple/swift-evolution/blob/master/proposals/NNNN-name.md)
Author: Patrick Gili (https://github.com/gili-patrick-r)
Status: Awaiting review
Review manager: TBD
Introduction
The Swift language has no native support for regular expressions, which makes working with regular expressions in Swift awkward, tedious, and error prone. This proposal describes the addition of regular expressions literals to Swift.

Swift-evolution thread: Empower String type with regular expression <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151228/005126.html>
Motivation
The definition of a pattern used by a regular expression is complicated by the fact that Swift does not support raw string literals (i.e., string literals that do not process character escapes or interpolation) or regular expression literals similar to Perl or Ruby. Rather, Swift only supports C-style string literals with support for interpolation. C-style string literals require a backslash to escape a backslash. The patterns representing regular expressions make frequent use of the backslash, and hence patterns represented by a Swift string literal become unreadable and difficult to maintain. For example, consider the following pattern to match and parse URLs:

^(https?:\/\/)?([\da-z\.-]+)\.([a-z\.]{2,6})([\/\w \.-]*)*\/?$
To define this pattern in Swift, an application needs to define a string, such as

let pattern = "^(https?:\\/\\/)?([\\da-z\\.-]+)\\.([a-z\\.]{2,6})([\\/\\w <smb://///w> \\.- <smb://.->]*)*\\/?$"
This later is obviously difficult to read and maintain.

Proposed solution
The proposed solution is to add regular expression literals to Swift, similar to regular expression literal support by other languages, such as Perl and Ruby. Regular expression literals differ from raw string literals in two primary ways. First, regular expression literals support string interpolation of the pattern, which allows an application to construct a regular expression at run-time. Second, a regular expression literal creates an instance of a NSRegularExpression, rather than an instance of String. The following example declares a regular expression for the purpose of matching and parsing URIs with a specified scheme:

let scheme = "https"
let urlRegex = /^(\(scheme)?:\/\/)?([\da-z\.-]+)\.([a-z\.]{2,6})([\/\w \.-]*)*\/?$/
To make regular expression literals effective, it must be possible to replace the creation of any instance of NSRegularExpression. The initializer for NSRegularExpression accepts a string describing the pattern and a set of options. To support these options, a regular expression literal accepts a list of zero or more options after the delimiter closing the pattern. For example, consider a regular expression to match and parse email addresses.

let emailRegex = /^([a-z0-9_\.-]+)@([\da-z\.-]+)\.([a-z\.]{2,6})$/
This regular expression will match "john.appleseed@apple.com <mailto:john.appleseed@apple.com>"", but not "JOHN.APPLESEED@APPLE.COM <mailto:JOHN.APPLESEED@apple.com>". The regular expression has to allow for this, as email addresses are not case sensitive. Rather than add the complexity to the pattern to account for this, the following example achieves the same:

let emailRegex = /^([a-z0-9_\.-]+)@([\da-z\.-]+)\.([a-z\.]{2,6})$/i
In this case, the "i" following the delimiter closing the pattern maps to RegularExpressionOption.CaseInsensitive.

Detailed design
The following modification to the grammar of a literal adds support for regular expression literals:

literal → numeric-literal | string-literal | boolean-literal | regex-literal | nil-literal

The following grammar describes a regular expression literal:

regex-literal → static-regex-literal | interpolated-regex-literal

static-regex-literal → / patternopt / regex-optionsopt
pattern → pattern_item patternopt
pattern_item → any Unicode scalar value except /, U+000A, or U+000D

interpolated-string-literal → / interpolated-patternopt / regex-optionsopt
interpolated_pattern → interpolated_pattern_item interpolated_patternopt
interpolated_pattern_item → ( expression ) | pattern_item

regex-options → regex-option | regex-optionopt
regex_option → i | x | q | s | m | d | b

The following table summarize the regular expression options:

Option RegularExpressionOption
i CaseInsensitive
x AllowCommentsAndWhitespace
q IgnoreMetacharacters
s DotMatchesLineSeparations
m AnchorsMatchLines
d UseUnixLineSeparators
b UseUnicodeWordBoundaries
Impact on existing code
The use of regular expression literals is opt-in, and hence there is no impact to existing code.

Alternatives considered
There have been several threads on the swift-evoluation mailing list that have discussed alternatives to regular expression literals.

String literal suffixes for defining types <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151214/002193.html> discussed string literals with a single character appended after the closing delimiter to denote the type. For example, the string literal r"\d+" in Python denotes a regular expression literal. However, this approach suffers from two disadvantages: 1) it does not support string interpolation in the pattern, and 2) it uses double-quotes for the delimiter, which appears more frequently in regular expressions than the forward slash.

Muli-line string literals <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151214/002325.html> discussed string literals spanning more than one line. This would be a worthy addition to the regular expression literal discussed in this proposal. We should consider modifying the grammar to support this. However, I wanted to introduce changes incrementally to maintain focus.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Patrick Gili) #10

Never mind, NSRegularExpression is in the Foundation.

···

On Jan 31, 2016, at 1:18 PM, Patrick Gili <gili.patrick.r@gili-labs.com> wrote:

There is one thing I want to discuss with regard to this proposal. I think NSRegularExpression is part of the standard library. If Swift were to support regular expression literal, wouldn't it make sense to move NSRegularExpression to the foundation?

Cheers,
-Patrick


#11

This seem to be two proposals in one:
1. Initialize NSRegularExpression with a single String which includes options

The ultimate goal based on the earlier mail in the thread seems to be able in a future proposal do thing like: string ~= replacePattern, if string =~ pattern, decoupled from the legacy Obj-C. Isn’t NSRegularExpression part of the legacy? The conversion of the literal string as regular expression should probably part of the proposal for these operators; as this is the time we will know how we want the text to be interpreted.

2. Easily create a String without escaping (\n is not linefeed, but \ and n)

The ability to not interpret the backslash as escape can be useful in other scenario that creating a NSRegularExpression; like creating a Windows pathname, or creating regular expression which are then given to external tool. So this part of the proposal should probably be generalized.

Dany

···

Le 31 janv. 2016 à 12:18, Patrick Gili via swift-evolution <swift-evolution@swift.org> a écrit :

Here is the link to the proposal on GitHub:

https://github.com/gili-patrick-r/swift-evolution/blob/master/proposals/NNNN-regular-expression-literals.md

Cheers,
-Patrick


(John Randolph) #12

Perl 6’s regex implementation looks like a logical progression of the grep style as we’ve come to know it over the years, but I’d really like to see Swift go with something like the Verbal Expressions approach.

https://github.com/VerbalExpressions/SwiftVerbalExpressions

All the power is there, but it’s far more readable.

-jcr

···

On Jan 31, 2016, at 7:39 PM, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:

On Jan 31, 2016, at 8:32 AM, Patrick Gili via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

There have been several threads that have discussed the notion of a regular expression literals. However, I didn't see anyone putting together a formal proposal, and hence I took the liberty to do so. I would appreciate discussion and comments on the proposal:

I am +1 on the concept of adding regex literals to Swift, but -1 on this proposal.

Specifically, instead of introducing regex literals, I’d suggest that you investigate introducing regex’s to the pattern grammar, which is what Swift uses for matching already. Regex’s should be usable in the cases of a switch, for example. Similarly, they should be able to bind variables directly to subpatterns.

Further, I highly recommend checking out Perl 6’s regular expressions. They are a community that has had an obsessive passion for regular expressions, and in Perl 6 they were given the chance to reinvent the wheel based on what they learned. What they came up with is very powerful, and pretty good all around.


(David Hart) #13

Hi Chris,

Which parts of the Perl 6 regexes do you think are interesting to keep for Swift? What you suggest also means dropping NSRegularExpression support for literals and instead introducing a Regex class in the stdlib. Correct?

David.

···

On 01 Feb 2016, at 04:39, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:

Further, I highly recommend checking out Perl 6’s regular expressions. They are a community that has had an obsessive passion for regular expressions, and in Perl 6 they were given the chance to reinvent the wheel based on what they learned. What they came up with is very powerful, and pretty good all around.


(Patrick Gili) #14

Hi Chris,

Thank you for the feedback; it is much appreciated.

I like the idea of folding this into the language's pattern grammar. It makes it more Swifty. I didn't see that direction, and I will investigate it further.

I have been looking a lot at Perl 6. In fact, a lot of languages these days use PCRE or PCRE2, which was based on Perl's implementation of regular expressions. Does this mean there is attitude to move away from the regular expression implementation used by the foundation today?

Cheers,
-Patrick

···

On Jan 31, 2016, at 10:39 PM, Chris Lattner <clattner@apple.com> wrote:

On Jan 31, 2016, at 8:32 AM, Patrick Gili via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

There have been several threads that have discussed the notion of a regular expression literals. However, I didn't see anyone putting together a formal proposal, and hence I took the liberty to do so. I would appreciate discussion and comments on the proposal:

I am +1 on the concept of adding regex literals to Swift, but -1 on this proposal.

Specifically, instead of introducing regex literals, I’d suggest that you investigate introducing regex’s to the pattern grammar, which is what Swift uses for matching already. Regex’s should be usable in the cases of a switch, for example. Similarly, they should be able to bind variables directly to subpatterns.

Further, I highly recommend checking out Perl 6’s regular expressions. They are a community that has had an obsessive passion for regular expressions, and in Perl 6 they were given the chance to reinvent the wheel based on what they learned. What they came up with is very powerful, and pretty good all around.

-Chris

Regular Expression Literals
Proposal: [SE-NNNN] (https://github/apple/swift-evolution/blob/master/proposals/NNNN-name.md)
Author: Patrick Gili (https://github.com/gili-patrick-r)
Status: Awaiting review
Review manager: TBD
Introduction
The Swift language has no native support for regular expressions, which makes working with regular expressions in Swift awkward, tedious, and error prone. This proposal describes the addition of regular expressions literals to Swift.

Swift-evolution thread: Empower String type with regular expression <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151228/005126.html>
Motivation
The definition of a pattern used by a regular expression is complicated by the fact that Swift does not support raw string literals (i.e., string literals that do not process character escapes or interpolation) or regular expression literals similar to Perl or Ruby. Rather, Swift only supports C-style string literals with support for interpolation. C-style string literals require a backslash to escape a backslash. The patterns representing regular expressions make frequent use of the backslash, and hence patterns represented by a Swift string literal become unreadable and difficult to maintain. For example, consider the following pattern to match and parse URLs:

^(https?:\/\/)?([\da-z\.-]+)\.([a-z\.]{2,6})([\/\w \.-]*)*\/?$
To define this pattern in Swift, an application needs to define a string, such as

let pattern = "^(https?:\\/\\/)?([\\da-z\\.-]+)\\.([a-z\\.]{2,6})([\\/\\w <smb://///w> \\.- <smb://.->]*)*\\/?$"
This later is obviously difficult to read and maintain.

Proposed solution
The proposed solution is to add regular expression literals to Swift, similar to regular expression literal support by other languages, such as Perl and Ruby. Regular expression literals differ from raw string literals in two primary ways. First, regular expression literals support string interpolation of the pattern, which allows an application to construct a regular expression at run-time. Second, a regular expression literal creates an instance of a NSRegularExpression, rather than an instance of String. The following example declares a regular expression for the purpose of matching and parsing URIs with a specified scheme:

let scheme = "https"
let urlRegex = /^(\(scheme)?:\/\/)?([\da-z\.-]+)\.([a-z\.]{2,6})([\/\w \.-]*)*\/?$/
To make regular expression literals effective, it must be possible to replace the creation of any instance of NSRegularExpression. The initializer for NSRegularExpression accepts a string describing the pattern and a set of options. To support these options, a regular expression literal accepts a list of zero or more options after the delimiter closing the pattern. For example, consider a regular expression to match and parse email addresses.

let emailRegex = /^([a-z0-9_\.-]+)@([\da-z\.-]+)\.([a-z\.]{2,6})$/
This regular expression will match "john.appleseed@apple.com <mailto:john.appleseed@apple.com>"", but not "JOHN.APPLESEED@APPLE.COM <mailto:JOHN.APPLESEED@apple.com>". The regular expression has to allow for this, as email addresses are not case sensitive. Rather than add the complexity to the pattern to account for this, the following example achieves the same:

let emailRegex = /^([a-z0-9_\.-]+)@([\da-z\.-]+)\.([a-z\.]{2,6})$/i
In this case, the "i" following the delimiter closing the pattern maps to RegularExpressionOption.CaseInsensitive.

Detailed design
The following modification to the grammar of a literal adds support for regular expression literals:

literal → numeric-literal | string-literal | boolean-literal | regex-literal | nil-literal

The following grammar describes a regular expression literal:

regex-literal → static-regex-literal | interpolated-regex-literal

static-regex-literal → / patternopt / regex-optionsopt
pattern → pattern_item patternopt
pattern_item → any Unicode scalar value except /, U+000A, or U+000D

interpolated-string-literal → / interpolated-patternopt / regex-optionsopt
interpolated_pattern → interpolated_pattern_item interpolated_patternopt
interpolated_pattern_item → ( expression ) | pattern_item

regex-options → regex-option | regex-optionopt
regex_option → i | x | q | s | m | d | b

The following table summarize the regular expression options:

Option RegularExpressionOption
i CaseInsensitive
x AllowCommentsAndWhitespace
q IgnoreMetacharacters
s DotMatchesLineSeparations
m AnchorsMatchLines
d UseUnixLineSeparators
b UseUnicodeWordBoundaries
Impact on existing code
The use of regular expression literals is opt-in, and hence there is no impact to existing code.

Alternatives considered
There have been several threads on the swift-evoluation mailing list that have discussed alternatives to regular expression literals.

String literal suffixes for defining types <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151214/002193.html> discussed string literals with a single character appended after the closing delimiter to denote the type. For example, the string literal r"\d+" in Python denotes a regular expression literal. However, this approach suffers from two disadvantages: 1) it does not support string interpolation in the pattern, and 2) it uses double-quotes for the delimiter, which appears more frequently in regular expressions than the forward slash.

Muli-line string literals <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151214/002325.html> discussed string literals spanning more than one line. This would be a worthy addition to the regular expression literal discussed in this proposal. We should consider modifying the grammar to support this. However, I wanted to introduce changes incrementally to maintain focus.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution


(Sune Foldager) #15

These two things seem somewhat orthogonal to me, but I am also much more excited about what you propose; many languages have regex literals, and that’s great, but allowing them in pattern matching with variable binding and efficient parallel execution is much rarer.

Standard regex literals isn’t too important for Swift, IMO. Writing /…../ or Regex(‘…..’) isn’t that different, really. Regex could be initialised from strings as well, making the difference even smaller.

-Sune

···

On 01 Feb 2016, at 04:39, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:

I am +1 on the concept of adding regex literals to Swift, but -1 on this proposal.

Specifically, instead of introducing regex literals, I’d suggest that you investigate introducing regex’s to the pattern grammar, which is what Swift uses for matching already. Regex’s should be usable in the cases of a switch, for example. Similarly, they should be able to bind variables directly to sub patterns.


#16

There have been several threads that have discussed the notion of a regular expression literals. However, I didn't see anyone putting together a formal proposal, and hence I took the liberty to do so. I would appreciate discussion and comments on the proposal:

I am +1 on the concept of adding regex literals to Swift, but -1 on this proposal.

Specifically, instead of introducing regex literals, I’d suggest that you investigate introducing regex’s to the pattern grammar, which is what Swift uses for matching already. Regex’s should be usable in the cases of a switch, for example. Similarly, they should be able to bind variables directly to sub patterns.

I was seeing the sub patterns originally a bit like:
switch( string <match-op> regex) {
  case .matches(_, "http", let port):
  case .matches(_, let name, "8080"):
  case .matches(_, "\\smb\"):
}
but the comment about the pattern grammar make me of:
switch( string ) {
  case regexp1: if ($0.1 = "http") { }
  case regexp2:
}
Both have their uses

Dany

···

Le 31 janv. 2016 à 22:39, Chris Lattner via swift-evolution <swift-evolution@swift.org> a écrit :

On Jan 31, 2016, at 8:32 AM, Patrick Gili via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Further, I highly recommend checking out Perl 6’s regular expressions. They are a community that has had an obsessive passion for regular expressions, and in Perl 6 they were given the chance to reinvent the wheel based on what they learned. What they came up with is very powerful, and pretty good all around.

-Chris


(Brent Royal-Gordon) #17

Further, I highly recommend checking out Perl 6’s regular expressions. They are a community that has had an obsessive passion for regular expressions, and in Perl 6 they were given the chance to reinvent the wheel based on what they learned. What they came up with is very powerful, and pretty good all around.

As someone who learned to argue about language design on perl6-language, you have my interest. :^)

How far do you want to go here? In the small, Perl 6 redesigned regex syntax to remove certain syntactic hacks and make more common operations more accessible; in the medium, they introduced extensibility and reusability with named rules; in the large, they made grammars of named rules a first-class language feature; and in the very large, they turned the parsing of Perl itself into a Perl grammar you could subclass and modify for metaprogramming. #1 and #4 are very different propositions.

···

--
Brent Royal-Gordon
Architechies


(Patrick Gili) #18

Hi Dany,

Please find my response inline below.

Cheers,
-Patrick

This seem to be two proposals in one:
1. Initialize NSRegularExpression with a single String which includes options

The ultimate goal based on the earlier mail in the thread seems to be able in a future proposal do thing like: string ~= replacePattern, if string =~ pattern, decoupled from the legacy Obj-C. Isn’t NSRegularExpression part of the legacy? The conversion of the literal string as regular expression should probably part of the proposal for these operators; as this is the time we will know how we want the text to be interpreted.

I don't see any evidence of NSRegularExpression becoming part of any legacy. Given SE-005, SE-006, and SE-023, the name is probably changing from NSRegularExpression to RegularExpression. However, I don't think the definition of the class will change, only the name.

I would like to see an operator regular expression matching operator, like Ruby and Perl. I was trying to keep the proposal a minimal increment that would buy the biggest bang for the buck. We can already accomplish much of what other languages can do with regard to regular expression. However, the notion of a regular expression isn't something we can work around with custom library today. Can you suggest something addition that should be in the proposal?

2. Easily create a String without escaping (\n is not linefeed, but \ and n)

The ability to not interpret the backslash as escape can be useful in other scenario that creating a NSRegularExpression; like creating a Windows pathname, or creating regular expression which are then given to external tool. So this part of the proposal should probably be generalized.

Generalize it for what? If you're thinking along the line of raw strings, I agree that we need this capability, as well as multi-line string literals. However, I just soon we have separate proposals for this.

···

On Jan 31, 2016, at 3:46 PM, Dany St-Amant via swift-evolution <swift-evolution@swift.org> wrote:

Dany

Le 31 janv. 2016 à 12:18, Patrick Gili via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> a écrit :

Here is the link to the proposal on GitHub:

https://github.com/gili-patrick-r/swift-evolution/blob/master/proposals/NNNN-regular-expression-literals.md

Cheers,
-Patrick

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Dave Abrahams) #19

It's more readable for a first-timer, but IMO not for anyone trying to
work with really complex regex's. Can you imagine doing math or music
this way? There's a reason people invent specialized notations.

···

on Sun Jan 31 2016, John Randolph <swift-evolution@swift.org> wrote:

On Jan 31, 2016, at 7:39 PM, Chris Lattner via swift-evolution >> <swift-evolution@swift.org> wrote:

On Jan 31, 2016, at 8:32 AM, Patrick Gili via swift-evolution > >>> <swift-evolution@swift.org >>> <mailto:swift-evolution@swift.org>> >>> wrote:

There have been several threads that have discussed the notion of a
regular expression literals. However, I didn't see anyone putting
together a formal proposal, and hence I took the liberty to do
so. I would appreciate discussion and comments on the proposal:

I am +1 on the concept of adding regex literals to Swift, but -1 on this proposal.

Specifically, instead of introducing regex literals, I’d suggest
that you investigate introducing regex’s to the pattern grammar,
which is what Swift uses for matching already. Regex’s should be
usable in the cases of a switch, for example. Similarly, they
should be able to bind variables directly to subpatterns.

Further, I highly recommend checking out Perl 6’s regular
expressions. They are a community that has had an obsessive passion
for regular expressions, and in Perl 6 they were given the chance to
reinvent the wheel based on what they learned. What they came up
with is very powerful, and pretty good all around.

Perl 6’s regex implementation looks like a logical progression of the
grep style as we’ve come to know it over the years, but I’d really
like to see Swift go with something like the Verbal Expressions
approach.

https://github.com/VerbalExpressions/SwiftVerbalExpressions

All the power is there, but it’s far more readable.

--
-Dave


(Patrick Gili) #20

Hi John,

I don't think this represents a good direction. IMHO, it is not as easy to read (or maintain) for two reasons:

1) The Unix grep and sed commands popularized a regular expression syntax that has been leveraged by numerous languages and libraries, and hence, most developers want that familiarity.

2) The syntax presented by Swift Verbal Expressions is noisy, and hence it lacks the clear and concise nature of the syntax used by grep and sed.

Cheers,
-Patrick

···

On Jan 31, 2016, at 10:48 PM, John Randolph <jcr@mac.com> wrote:

On Jan 31, 2016, at 7:39 PM, Chris Lattner via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

On Jan 31, 2016, at 8:32 AM, Patrick Gili via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

There have been several threads that have discussed the notion of a regular expression literals. However, I didn't see anyone putting together a formal proposal, and hence I took the liberty to do so. I would appreciate discussion and comments on the proposal:

I am +1 on the concept of adding regex literals to Swift, but -1 on this proposal.

Specifically, instead of introducing regex literals, I’d suggest that you investigate introducing regex’s to the pattern grammar, which is what Swift uses for matching already. Regex’s should be usable in the cases of a switch, for example. Similarly, they should be able to bind variables directly to subpatterns.

Further, I highly recommend checking out Perl 6’s regular expressions. They are a community that has had an obsessive passion for regular expressions, and in Perl 6 they were given the chance to reinvent the wheel based on what they learned. What they came up with is very powerful, and pretty good all around.

Perl 6’s regex implementation looks like a logical progression of the grep style as we’ve come to know it over the years, but I’d really like to see Swift go with something like the Verbal Expressions approach.

https://github.com/VerbalExpressions/SwiftVerbalExpressions

All the power is there, but it’s far more readable.

-jcr