[swift-evolution] Empower String type with regular expression

[Jacob Bandes-Storch]

It'd be trickier, but you could imagine allowing the user to declare a
custom delimiter for their "verbatim literals", so a Regex type would use a
"/".

Ruby, for example, has string literal constructs which allow a wide range
of delimiters: https://simpleror.wordpress.com/2009/03/15/q-q-w-w-x-r-s/
 (and Perl as well, I believe)

Jacob

On Tue, Dec 8, 2015 at 3:19 PM, Kametrixom Tikara via swift-evolution <
swift-evolution at swift.org> wrote:

> I think we can extend this to something more general:
> VerbatimLiteralConvertible. A VerbatimLiteral would maybe start with a \"
> and end with "\ (Might not work with these delimiters). It would enable one
> to not have to escape special chars like " and \, so that they can be used
> just like that:
>
> let verb = \"And he said: "\o/""\
> let file = \"
> First line
> "Still in verbatim!
> "\
>
> We could then use this for the Reges type like:
>
> struct Regex : VerbatimLiteralConvertible {
>     init(verbatimLiteral value: String) {
>         ...
>     }
> }
>
> extension String {
>     func match(regex: Regex) -> Range<String.Index>? {
>         ...
>     }
> }
>
> let matches = string.match(\"[a-z]"test"\)
>
> Such a VerbatimLiteral also has the advantage of being able to copy-paste
> potentially big regex expressions in your code without the need to manually
> add all those "\" for escaping. Also it can be used to directly copy-past
> some text with correct line breaks and indentation.
>
> I'd really love to see this, I'm just unsure of how the parser could
> delimit such a VerbatimLiteral.
>
> Kame
>
> > On 08 Dec 2015, at 23:41, Brent Royal-Gordon via swift-evolution <
> swift-evolution at swift.org> wrote:
> >
> >
> >> 1. The semantics of the =~ operator in other languages maps to a return
> value of Int? - matching position or nil with no match. This means you
> would likely need to write if str =~ foo != nil { … }
> >
> > Actually, I suspect the return value would be more like
> Range<String.Character.Index>?, or maybe even Regex.Match?.
> >
> >> 2. The semantics of the =~ operator produce state around matched
> groups, which is usually exposed to the language as either thread-local or
> block-local data.
> >
> > This is hugely dependent on the language and I think it’s pretty obvious
> that Swift would take a return-value-based approach:
> >
> >    if let match = string =~ /”([^\\”]*(\\[\\”][^\\”]*)*)”/ {
> >        let quotedString = match.substrings[1]
> >        …
> >    }
> >
> >> For regex literals, my only concern is that it makes regex a language
> feature over an extended or standard library feature.
> >
> > Not necessarily. The only thing that *has* to be in the language is
> support for parsing regex literals, and the only thing that has to be in
> the standard library is RegexLiteralConvertible. Even if there is a Regex
> type in the standard library, just that type could be dropped there without
> requiring huge compiler changes.
> >
> > --
> > Brent Royal-Gordon
> > Architechies
> >
> > _______________________________________________
> > swift-evolution mailing list
> > swift-evolution at swift.org
> > https://lists.swift.org/mailman/listinfo/swift-evolution
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151208/48d8b4d7/attachment.html>