There is probably a good reason Swift doesn't have regex literals, regex operators, and other such things. These things are not common in statically, strongly typed languages with an emphasis on safety.
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 "stringly typed" code, message passing using strings as data structures, and an emphasis on string and array operations.
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'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't a first-class citizen in those languages.
I'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.
tl;dr: Even as someone not invested in iOS or OS X development at all, given the chance I'd veto these features. Give me types, not strings.
Having amazing string capabilities is more important now than ever. But that actually argues against including regex in the language syntax itself. You want regular expressions to be able to evolve to become ever more powerful and useful.
So just include a literal string type in the language itself--one that minimizes the need for escapes and can be used for all sorts of protocols--and use a regex library. The syntaxes of the library and the language can then evolve somewhat independently, and if it reaches a point where you need a non-backwards-compatible change in the regular expression syntax for some great new innovation, people who still need the old one can continue to import the old library, while others can import the new one.
The freedom of technologies to work together yet evolve independently is an important "feature" that's worth protecting.
Aside from these reasons, you also have the case of performance optimization. In Perl, for example, pretty much all string parsing (that I've ever seen done in Perl code) is done via regular expressions. Regular expressions in Perl are such a thing that most software I've used that uses regular expressions uses the Perl-compatible regular expression library (libpcre).
The issue is that if you provide developers with a simple method of e.g. splitting a string using regular expressions, then they will always split their strings with regular expressions. This is rarely the most optimal way of doing it, however, and it requires more memory and more overhead than e.g. splitting a string by simply scanning it.
The reason this is a problem for Swift in particular is mobile devices, where memory and CPU use is more costly than on desktop software.
I don't think it's coincidence that all the languages I'm aware of which natively support regexes as part of the language syntax are interpreted/scripting languages where performance is not the language's primary concern (Python being one such language with this syntax notably absent), whereas the language that the grandparent comment listed for 'safer languages' which do not have regex literal support ("Java, C#, Go, Rust, Haskell, or to be charitable, C++") are all compiled languages where performance is assumed to be part of the primary concern for the language design and for developers in the language.
"more memory and more overhead than e.g. splitting a string by simply scanning it."
Regexes are simply scanning strings, they're just a more condensed syntax for specifying how the scanning should be done.
And in interpreted languages, using the built-in regex feature (which can apply high-level optimizations) will virtually always give much better performance than implementing the same logic by manually looping over the string character-by-character with the language's interpreted for/while loops.
I think the reason is that it's a brand new language that has unimplemented and missing features. Regex as a first-class citizen seems like it absolutely fits into the goals that Swift has and I would be very surprised if its long-term exclusion is intended.
I agree more with the parent on this one. I would actually expect GCD to receive first class language features before regex. There are certain operations like @sync that made their way into objective-c and Swift can use some language features to implement very common patterns in iOS/OS X programming.
Then again, in Swift you can declare your own operator and call into NSRegularExpression.
I don't think regexp support has a lot to do with being "stringly typed". In fact, regular expressions are one of the best tools to avoid that antipattern in scripting languages, because they allow you to easily analyze string input and construct an internal representation from it. I think it's more that most of the scripting languages originally grew around the task of text processing (e.g. as system scripts), so their facilities for dealing with text are great. Languages like Java, C#, Go, Haskell, etc., had more of a focus on general computing.
I think that is a good point, and one that comes up when working with SQL. Even though the relational algebra does joins by the name of attributes, and it's common to filter according to patterns, parameterized statements are an important best practice.
I think in the specific case of Haskell, parser combinator libraries like Parsec are so nice that it can be more convenient to use parser combinators than regexes for parsing regular languages. I'm haven't seen similar substitutions in other languages.
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 "stringly typed" code, message passing using strings as data structures, and an emphasis on string and array operations.
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'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't a first-class citizen in those languages.
I'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.
tl;dr: Even as someone not invested in iOS or OS X development at all, given the chance I'd veto these features. Give me types, not strings.