Regex in Swift

There is probably a good reason Swift doesn&#x27;t have regex literals, regex operators, and other such things. These things are <i>not common</i> in statically, strongly typed languages with an emphasis on safety.<p>That could be pure correlation. Perhaps it is just coincidence that JavaScript, PHP, Perl, and a handful of others happen to have a lot of &quot;stringly typed&quot; code, message passing using strings as data structures, and an emphasis on string and array operations.<p>Or it could be that such features, due to their ease of use and the turing-tarpit of powerful enhanced regular expression languages, developers fall into the allure and trap of stringly typed code. And safe languages are the languages that don&#x27;t make it exceedingly easy to use regular expressions. Because there is no reason you cannot use regular expressions in safer languages like Java, C#, Go, Rust, Haskell, or to be charitable, C++. It just isn&#x27;t a first-class citizen in those languages.<p>I&#x27;m of the view that if you make your language such that idioms prone to error and bad practices easy, then developers will be prone to error and bad practices.<p>tl;dr: Even as someone not invested in iOS or OS X development at all, given the chance I&#x27;d veto these features. Give me types, not strings.

The author is maybe not aware that there&#x27;s already a convenience form that doesn&#x27;t require explicitly making an NSRegularExpression object.<p><pre><code> if name.rangeOfString(&quot;ski$&quot;, options: .RegularExpressionSearch).location != NSNotFound { println(&quot;\(name) is probably polish&quot;) } </code></pre> That&#x27;s existing Cocoa API; in Swift (hopefully!) the API can be updated to return nil if there&#x27;s no match, so that it can read<p><pre><code> if let match = name.rangeOfString(&quot;ski$&quot;, options: .RegularExpressionSearch) { println(&quot;\(name) is probably polish&quot;) } </code></pre> which I don&#x27;t think is too bad!

This feature is crying out for procedural macro support, not for being built into the language. For comparison, Rust has compile-time regular expressions (which, I will note, this blog post does not do; it&#x27;s all runtime-parsed), implemented as a separate library that ships with Rust, using the procedural macro support (also called syntax extensions). This means the compiler and the language spec knows _nothing_ about regular expressions, and only the library libregex knows anything about it, and if you don&#x27;t link against libregex, your program has no knowledge about it.<p>This ends up looking like the following:<p><pre><code> #![feature(phase)] &#x2F;&#x2F; feature-gate for syntax extensions #[phase(plugin)] &#x2F;&#x2F; tells the compiler the following crate has syntax extensions extern crate regex_macros; &#x2F;&#x2F; a crate is a rust library. this one provides the syntax extension extern crate regex; &#x2F;&#x2F; this one provides the runtime support for regular expressions fn main() { let re = regex!(r&quot;^\d{4}-\d{2}-\d{2}$&quot;); &#x2F;&#x2F; compile-time regular expression assert_eq!(re.is_match(&quot;2014-01-01&quot;), true); } </code></pre> That `regex!(...)` call will trigger the compile-time syntax extension to parse the regular expression, throw a compile-time error if the parsing fails, and otherwise expand to an inline data structure that contains the runtime representation of the parsed regular expression. Even better, it generates native Rust code for various bits of the matching process, instead of relying on the generalized implementation used for runtime-parsed regular expressions, which means it&#x27;s actually faster to use a compile-time regex. The downside is, of course, that it&#x27;s generating specialized code for each one, so this can bloat your binary if you use a lot of regular expressions, but on the upside turning on Link-Time Optimization can get rid of a lot of this overhead.

From the radar issue submission:<p>&gt;<i>Any modern language should natively support regular expression literals</i><p>Regex literals add needless complexity to the language, and tie it with a specific regex implementation, with no real benefit.<p>Just because Perl&#x2F;JS&#x2F;Ruby have this kludge, doesn&#x27;t mean a modern language &quot;should&quot; have it.<p>Now, a way to write unescaped strings (e.g not having to escape all the regex operators like \ etc), that I can stand behind.

&gt; once Apple reads my radar and implements &#x2F;regex&#x2F; literal syntax<p>jesus, get over yourself.

How about something like <a href="http://www.inf.puc-rio.br/~roberto/lpeg/" rel="nofollow">http:&#x2F;&#x2F;www.inf.puc-rio.br&#x2F;~roberto&#x2F;lpeg&#x2F;</a> ?<p>Since the optional pattern syntax doesn&#x27;t use backslashes, they aren&#x27;t a problem. I&#x27;d hack this up myself if Swift weren&#x27;t Apple-only.

Custom operators for all things ! or how to make your code base unmaintainable

&quot;Please tack on this random application-specific feature that I like&quot;<p>Can we add supprt for overloading the comma operator? How about the mail function from PHP?