SE-0354: Regex Literals

[tem (GalaxySwift)]

@hooman

Also, #/.../# will behave differently in how it interprets / and this by itself will cause compatibility issues.

If I'm reading the discussion right in the old [Pitch] Regex Syntax - #12 by Michael_Ilseman and the current draft of Regex Syntax and Runtime Construction then escaped slashes would be treated the same in both bare and extended literals:

A metacharacter may be treated as literal by preceding it with a backslash. Other literal characters may also be preceded by a backslash, in which case it has no effect, e.g \% is literal % . However this does not apply to either non-whitespace Unicode characters, or to unknown ASCII letter character escapes, e.g \I is invalid and would produce an error.

Because backslashes are not treated as literal in "raw"/extended literals (unlike raw strings).

This syntax differs from raw string literals #"..."# in that it does not treat backslashes as literal within the regex. A string literal #"\n"# represents the literal characters \n . However a regex literal #/\n/# remains a newline escape sequence.

So the backslashes in #/\/path\/to\/files/# would just be redundant.

@hooman

That is why I proposed we start with something that does not use balanced # s. For example, #re/.../ which would interpret '/' exactly the same as /.../ and would get extended behavior when used as #re/.../# or #re#/.../# , and then consider #/.../# family as its shorthand syntax.

I can kind of see the logic there, but I could ask: why is there no shorthand for the non-extended #re/.../ ? It seems like either way you approach the #/.../# syntax it would be odd not to have the bare version.