possible SIP for changes to escapes in string interpolation

[SethTisue]

(not the same as #3 (backticks in string interpolation), but closely related)

this is about possible changes to resolve the issue where everyone expects s"\"$foo\"" to work but it doesn't. no proposal yet, but @somsnytt is interested

there has already been multiple discussions on this. see:

• https://issues.scala-lang.org/browse/SI-6476
• https://groups.google.com/d/msg/scala-debate/HKe0BbiPkM8/xxYJke3pUAMJ
• https://groups.google.com/d/msg/scala-debate/7x2LF3VPGuk/4Bn5HTV1AgAJ

[som-snytt]

I started a write-up on vacation, because there is no life/volunteer balance anymore.

The new impetus is "Enable interpolators to behave like string literals." That includes that an interpolator (non-macro) should know if it's processing singly- or triply-quotedly.

No corpses should rise from past discusses to complain, What do you meeean, I can't do x?

[dickwall]

Request for status update for Sept 10th SLIP meeting

[som-snytt]

The SIP is at

https://github.com/som-snytt/scala.github.com/commit/791ae01bd1d956d8ad38b760694e4b07c92a9327

and impl

https://github.com/scala/scala/pull/4308

but it would be nice to include "string literals are just an apply-interpolator"

https://github.com/scala/scala/pull/4468

https://github.com/som-snytt/scala/commit/25258fded753c5fb138dc78cfba8291963b5dfe7

in so far as there are hints about differentiating literals and interpolated strings (because of singleton types, I think was the context) so this might be a last chance to unify them syntactically.

[dickwall]

@jsuereth to follow up with @som-snytt

Escaping double quotes is a common issue. Need to solve at least the newcomer experience.

[som-snytt]

@jsuereth @dickwall Sorry I didn't get an update in time for the slip meeting.

I don't suppose it's possible to slip the slip meeting?

Seriously tho', if there's a sense that it's worth pursuing, I'll make a shorter-term effort for 2.12.

I got a sense that a non-trivial solution would meet resistance.

Warn me if the scope is just, "Improve error messages on borked string escapes".

My goal was to virtualize string constant handling, which would be a default "apply" StringContext macro that behaves like ordinary string constants. (Parses the same, results in a string literal.)

As with any interpolator, you can scope your own and override default behaviors: either by actually interpolating, or by nuancing the "missing interpolator" warnings that annoy some people, or even doing i18n.

The hang-ups are:

1) detecting the end of the string may require examining the whole line (trying to be intuitive about escaped quotes).

2) the raw interpolator is raw modulo the required escape-awareness (\\, \$, \"). So raw"\"hi\"" means the interpolator sees the whole string, but by design it doesn't process the escapes. A beginner, if a beginner experiments with arcana, would hopefully get the message early that to do whacky stuff, use triple quotes, as becomes reflex when writing regexes.

This is for single quotes, s"text". Interpolators would be aware if they are triply-quoted. Currently, "\\" is different from """\\""", but s"\\" is the same as s"""\\""". These choices are up to the interpolator.

A regex interpolator could warn when it sees backslashes in a single-quoted string, which is javaesque recipe for confusion.

This comment is to refresh my memory.

[SethTisue]

@som-snytt are you interested in having @jvican take this up again?

[som-snytt]

@SethTisue Yes, I think my last comment still stands. My biggest motivation was for what the note calls "virtual string constants", where ordinary literals are processed by a default "apply" interpolator. The goal was to enable interpolation without the s prefix tax.

[SethTisue]

Closing since this repo is being decommissioned. This proposal could still be revived under the current SIP process.