It would be nice to include a preceding commit with a neg test to show that these cases were all parse errors before this patch.

I was always wondering why $" is preferable to \" for a double-quote escape. Could you elaborate on that?

@xeno-by Maybe I'll elaborate in the SIP document.

@xeno-by Actually, the SIP already says:

Expression syntax is required because no escape characters are interpreted
when parsing processed string literals:

    scala> s"I coulda been \"${who}body.\""
    <console>:1: error: ';' expected but '.' found.
           s"I coulda been \"${who}body.\""
                                       ^

Imagine a localization macro that converts \"quotes\" to «guillemets».

Isn't that just adding an additional way to do the same thing?

What's the improvement of e. g.

s"<$`foo$bar`"

over

s"<${foo$bar}"

?

@soc The point of that example is just that you get s"$anyid" where anyid is any Scala identifier of any ilk, except that $ must be backquoted if you abjure (not to say abhor) braces.

Conversely, though,

`foo$bar`

is permitted in Scala even though it's just another way to write foo$bar.

@som-snytt I agree that \" is something that will have to be special-cased. However $" is also a special-case, so in that regard these solutions are on par. Maybe there's something else about $" that I'm overlooking?

@xeno-by I misunderstood you.

f"%2$$s $foo $bar" is not especially fortunate, compared to \$. Similarly, if searching for dollars, r"\$$+" for, let's see, r"\\$+" if it's not necessary to escape the escape.

If \" and \$ were preprocessed, then interpolators would have to special-case them as well. Maybe there are other args against that path.

OTOH, $cala loves dollars. There must be a s"$m$$$$anonfun$i" somewhere in the compiler, right?

In a word, I sympathize but the gist of the discussions weighed against special-cased escapes. In one thread linked from SI-6476, Martin's phrase is "ugly special case." Even though he agrees that the behavior is not intuitive, or intended.

I think a case might be made for guillemets. Then we could discuss how to pronounce guillemets.

@retronym Not all are parse errs, because the foo_* case consumes more input than previously. That's the breaking change for s"$foo_*".

I'm going to close this PR. We'll get back to the SIP review process after the summer, at which time the greek tick and calming "all is well" on this PR will be duly noted.

I just needed this. s"Finished $status_?". Just some POC slash test code, but that makes ease of typing even more pleasant. In case anyone @retronym cares.

For the record, also surprising how often I would use ss map s"Done with $_".