Update RegexLiteralPitch.md with thread feedback

[milseman]

No description provided.

[milseman]

@hamishknight I think it makes sense to work on a v2 pitch that:

1. Discusses alternate delimiters more prominently
2. Clarifies exactly what the interior syntax is (e.g. superset of PCRE / UTS#18 / ICU?)
3. Reworks the parsing ambiguity section a little bit so it's clear at a glance what we're actually proposing on changing and where the questions are

[milseman]

For #1, I think it makes sense to have it under "Alternatives Considered" and simply present all the options people surfaced during the thread. If we have thoughts or rationale on a favored alternative, we can supply that, or at least order or otherwise comment on their potential advantages. The story is that we're totally still considering alternatives, we just signed up for an investigation into making / work, which is useful for evaluating the alternatives. We're still waiting on API to see the usage, so it's premature to declare a definite backup delimiter.

I think a lot of the reworking is slight adjustments or tweaks to what or how we're presenting to make it clear:

Our basic approach is:

• If Swift shipped with this, it would've been pretty natural
• Informal encouragement from core team to see if it's not "too late", given "acceptable costs"
• This pitch is discussing 3 purely-syntactic areas:
  • The current status of that investigation into using /
  • The syntax of the literal itself (superset of PCRE and UTS18)
  • The library-extension story (though strawperson-ed until we have more of our loose ends tied up)

Our current results are that this is not an issue for a lot of things, and we can make use of disclosure triangles for details:

<details><summary>Rationale</summary>
blah blah blah
</details>

Straw-person outline of the investigation:

• No changes:
  • Comments: we reject empty
  • Infix operators containing /: we require whitespace to disambiguate regex
  • Division operator /: we prefer current parsing behavior, but see "Unknown"
• Potential changes:
  • Language mode to deprecate / in prefix/postfix operators
• Unknown:
  • How to fix result builder parsing issue
    • This is a general issue, great to fix in general, but not sure about feasibility
    • Obviously we want regex literals in result builders, this could necessitate a choice of other delimiter if not addressed

[kylemacomber]

I think the comprehensive listing of alternatives is nice. Ideally we'd include some language that argues a little more strongly for the // syntax in the main part of the pitch as well. Also it'd be nice to a clear recommended direction for the listed issues.

[milseman]

The problem is, neither Hamish nor I are keen on / (and personally I really don't care for it). We're going with it because of informal encouragement from the core team to see if it can be done with acceptable cost, so a component of this pitch is that investigation. I think it's fair to present it this way, as an investigation suggested by the core team, and give a good treatment to alternatives

[milseman]

So I'd present this pitch as covering 3 areas:

1. A direction for the interior syntax (PCRE + any UTS#18 or other extensions such as more character classes or literal syntax)
2. A straw person compiler-library interaction story
3. An investigation into / as a delimiter, its results, and some light treatment/discussion of alternatives

[milseman]

@hamishknight I'm closing the PR, but feel free to yank prose from it if helpful.