> Well, seems more like syntactic sugar for a literal and a method call. A literal has a literal representation in code.
OK... but overall not a bad solution, right? Think of it as a string literal which makes itself amenable to idiomatic string interpolation. There would be no way to get real string interpolation with a method call.
> If you want to replace certain parts of a string with the value of that string when interpreted as code, this would be a method that is related to “interpret” and less to “format”
That's actually not what I want to do. In the idea I'm proposing, the resulting code will not produce run-time errors from parsing, as you would potentially get with `interpret`. The variable names and syntax can be parsed as correct or incorrect at compile-time. That is to say, if you write:
f"My uncle is \(name.scramble)" (using Swift syntax)
and the identifier `name` has not been defined yet, you would get a compile-time error. I think what you are suggesting is that first the string would be compiled, then the interpreter would be invoked again to parse the string `name.scramble`, and only then would produce a run-time error. This is undesirable for a number of reasons - first, we would like to get errors as early as possible when code is incorrect. Second, we would like to avoid invoking the interpreter machinery unnecessarily for such a simple task, and for one that would conceivably used quite frequency. Third, if this is meant to be suggested as an alternative to or replacement for .format, it should provide a similar experience and efficiency.
-Brian