To me, regexes definitely feel like they belong in Foundation. Also, I don’t 
think they’d be well-served by a literal syntax (even just 
ExpressibleByStringLiteral) because this privileges using the default regex 
options over specifying non-default options. 

The compilation issue seems a bit tricky, especially if Regex is a value type. 
To avoid throwing away a cached compiled version of the Regex, you’d need to 
remember to compile it before passing it to a function. Perhaps the 
initializers could have a `precompile` argument so that you’d never forget to 
compile the regex. The Swift compiler could then optimize around that where 
possible. It should definitely be possible to create uncompiled regexes, 
though. I also agree that the compiler should warn about invalid regexes where 

> On Aug 10, 2017, at 2:30 PM, Dave DeLong via swift-evolution 
> <> wrote:
>> On Aug 10, 2017, at 11:48 AM, Tino Heth via swift-evolution 
>> <> wrote:
>> I guess everyone agrees that there should be support for regular expressions 
>> - I'm just not sure where, how and when to integrate it…
>> People seem to have a (sometimes unhealthy…) passion for regex, so I'd like 
>> to encourage a critical look on their importance.
>> For example, I don't think they belong into the stdlib — there are more 
>> basic (and much more simple) things like a Result-type or an operator for 
>> function concatenation which are not included, so why should we treat 
>> regular expressions differently?
>> But It doesn't look like we'll see a fitting library that's bundled with 
>> Swift anytime soon, and third-party regex Frameworks imho would cause big 
>> confusion.
> This goes back to the idea of “non-standard libraries” that ship with Swift, 
> but aren’t imported by default. I think a “Swift.Regex” module would be 
> awesome, but I agree that it probably doesn’t need to be in the standard 
> library.
> Dave
>> Anyways, as you suggest a special syntax, it would be required to integrate 
>> support into Swift itself… although this is even deeper than the stdlib, I'm 
>> more positive towards that direction, as it would allow some neat tricks:
>> The expressions could not only be checked, but also translated at compile 
>> time — which could give Swift a real kickstart to beat established solutions 
>> in terms of execution speed.
>> It would, on the other hand, not work for non-literal strings, so regular 
>> expressions that are created at runtime would still need extra support…
>> If Core would consider to include compile-time regular expressions in the 
>> future, I'd support adding the new syntax, even if it's only used like 
>> NSExpression in the first implementation. Without that option, I think it's 
>> not worth it, and I'd rather try to use custom operators to build matchers 
>> that don't follow any regex standard, but are fast and safe to use.
>> _______________________________________________
>> swift-evolution mailing list
> _______________________________________________
> swift-evolution mailing list
swift-evolution mailing list

Reply via email to