It's the trivial cases that are compile time. The interesting templating is done with input that isn't defined within the source, and those can't be run entirely at compile time.
> And you automatically get things like safe SQL queries with parameter binding instead of injection vulnerabilities.
That's been solved for decades with parameterized queries (binding variables), and doesn't require interpolation in any way (at least not in the context we're using it here, but probably not at all in most DB drivers and engines). In fact, I would go so far as to say if someone is trying to use string interpolation instead of parameterized queries to avoid SQL injection, they've fundamentally misunderstood the problem and are trying to solve it at the wrong layer.
Also, if the string interpolation for the query is done at compile time, what type of content known at compile time is something that we'd be worried about SQL injection being in?
SQL doesn't require interpolation, but it's much cleaner to write it that way and not have to explicitly do binding. It's not an "instead." Like I said, what the interpolator does is automatic safe binding with interpolation syntax.
The content known at compile time is the query template that you're binding. The point is a compile-time interpolator turns e.g. `sql"""select * from users where name=$name"""` into `Statement("select * from users where name=?").bind(name)`.
You can also have macro fragments as "inline def" functions in e.g. Scala so that they compose naturally. c.f. Quill[0].