Class BacktickRewrite

java.lang.Object
org.ek9lang.compiler.support.literals.BacktickRewrite
All Implemented Interfaces:
BiFunction<String,Boolean,String>
final class BacktickRewrite extends Object implements BiFunction<String,Boolean,String>
THE rewrite of a double-quoted String's text as a backtick String, delimiters included - use InterpolatingBacktickString or LiteralBacktickString, the two spellings it gives; never re-derive it.

EK9 has two String literals. A double-quoted String is plain text and is never interpolated, so a ${...} inside one prints as those characters — almost always a misunderstanding carried from Kotlin, Groovy, Dart, PHP or a shell, where double quotes DO interpolate. The compiler therefore rejects ${ in a double-quoted String (E07901). A backtick String is interpolated: ${...} evaluates, and \$ writes a literal dollar.

🔑 So such a text has exactly two backtick spellings, and both come from here: interpolating (every ${...} evaluates — what the writer almost always meant) and literal (every ${ kept as characters). Both escape what a backtick String needs and a double-quoted one does not — a $ that opens no interpolation, and a backtick — write \" as a plain " (a backtick String needs no escape for it), and carry every other escape pair (\n, \$, ...) over as written. The concatenation rewriter renders its literal segments through the literal spelling too, so there is one rule for all three.

The compiler's E07901 message and the tooling's applied repair both call this, so the spelling the message names is always the spelling the repair writes. The second argument is true for the interpolating spelling.