[Returned for Revision] SE-0354: Regex Literals

[breathe (B Cohen)]

@Lantua

The problem with the "Swift could've done better" expression is that it does not suggest anything in particular, nor does it state the problem. At best, I see that the argument is that regex is arcane.

I think the argument is more specific than that -- you can't interpret a sequence of regexp characters without internalizing the entire set of control and escape characters -- full stop that makes PCRE hard to read and learn (I suppose that's an opinion, but I think it is accurate to say that PCRE is hard to learn ...). A syntax which required delimiters around terminals would be much more readable and easier to learn since as the reader you know exactly which characters have 'special meaning' and which represent 'just characters to match' [Pitch] Regular Expression Literals - #4 by breathe

That may be true (and likely is), but it’s also rather hard to find an equally concise syntax that is easily recognizable/understandable for those in on such arcana. Any alternative will have to be much, much better than regex as one also needs to justify not using regex.

I just don't buy that argument ... I advocated that the proposal should include scenarios representative of the real-world use cases to which these kinds of tools are applied. In my mind the basic scenario in which these expressions will evolve in a codebase is along these lines:

(1) you are given an informally specified/ad-hoc format defined by some number of examples
(2) you build a thing to do a thing (validate it obeys some constraints or get some data out of it)
(3) more examples of the language/format come in on which your code now breaks
(4) edit the patterns to fix; rinse and repeat

A sequence of examples showing the evolution of a set of literals given a scenario like that would allow alternative literal designs to be compared/contrasted along far more meaningful and practical dimensions than any of the discussions about the literal design achieved ...